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]

Date:	Mon, 04 Aug 2008 12:20:45 -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 19:39 +0100, Hugh Dickins wrote:

> Well, I guess put the check on ->readpage into your code for now, and
> by the time GEM gets into Linus's tree, we should have -EINVAL checks
> on NULL filler() in __read_cache_page() and read_cache_page_async(),
> so remove check at your end before final submission.

Sounds good to me.

> I think you should drop the mark_page_accessed(): that's done in
> read_cache_page_async() as part of the initial read_mapping_page().
> But do it again when releasing if you think there's a good chance
> that object will be wanted again shortly.  set_page_dirty() if
> modified by GPU, yes, that would still be needed.

I'll just remove it then; pages pulled from the GTT are unlikely to be
used soon.

> For how long are these objects' pages pinned in memory like this?

Forever? The only reason an object would get unpinned would be on
eviction from the GTT, and objects will only be evicted if we fill the
aperture with other stuff. When we add a register_shrinker callback,
we'll also unpin pages at that point.

A busy system should have the GTT entirely full, and that will be
somewhere between 256MB and 1GB.

> I ask because Rik & Lee have patches in -mm, trying to avoid long
> scans of LRUs cluttered with unevictable pages.  I've no idea
> whether you're adding a lot or a little to that problem.

If the idea of 1GB of pinned memory doesn't scare you, then I don't see
a problem ;-)

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

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