linux-kernel - Re: [PATCH] Export shmem_file_setup and shmem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1217885869.24714.97.camel@koto.keithp.com>
Date:	Mon, 04 Aug 2008 14:37:48 -0700
From:	Keith Packard <keithp@...thp.com>
To:	Hugh Dickins <hugh@...itas.com>
Cc:	keithp@...thp.com, Nick Piggin <nickpiggin@...oo.com.au>,
	Christoph Hellwig <hch@...radead.org>,
	Eric Anholt <eric@...olt.net>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Export shmem_file_setup and shmem_getpage for DRM-GEM

On Mon, 2008-08-04 at 20:55 +0100, Hugh Dickins wrote:

> Okay, thanks for the warning.  It sounds like the shrinker will be
> important, but we'll also need to mark those pages as unevictable
> while they're unshrunk.

That seems like a sensible optimization; otherwise the system could
spend quite a bit of time wandering over these pages.

>   (Usually when drivers grab a large number
> of pages, they're not on any LRU to begin with: you're being nice
> by choosing swappable LRU pages - in the tmpfs case - but enough
> to upset the balance while they're not swappable.) 

It's not a matter of 'being nice', of course, it's a matter of keeping
the system running under heavy firefox load. Check out the memory usage
by your X server with numerous tabs open to image-heavy pages someday.
Not making those pageable would result in OOM visiting far too often.

Right now, we make these images pageable by copying them in and out of a
set of pages bound permanently to the GTT. The performance implications
of doing that are fairly severe, enough so that in many cases it's
better to just use the CPU for most rendering.

>  Offhand I can't
> say what will be the appropriate way to do that, it's something we
> need to revisit later (from your point of view it should amount to
> one function call or flag set somewhere, not any grand redesign).

Ok, cool. I haven't added the shrinker support yet in any case, although
that doesn't look like a big job.

-- 
keith.packard@...el.com

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)