linux-kernel - Re: [PATCH v2 00/10] evacuate struct page from the block layer, introduce __pfn

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: <20150507194832.GB23511@gmail.com>
Date:	Thu, 7 May 2015 21:48:32 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Jerome Glisse <j.glisse@...il.com>
Cc:	Dave Hansen <dave.hansen@...ux.intel.com>,
	Dan Williams <dan.j.williams@...el.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Boaz Harrosh <boaz@...xistor.com>, Jan Kara <jack@...e.cz>,
	Mike Snitzer <snitzer@...hat.com>, Neil Brown <neilb@...e.de>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	Chris Mason <clm@...com>, Paul Mackerras <paulus@...ba.org>,
	"H. Peter Anvin" <hpa@...or.com>, Christoph Hellwig <hch@....de>,
	Alasdair Kergon <agk@...hat.com>,
	"linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
	Mel Gorman <mgorman@...e.de>,
	Matthew Wilcox <willy@...ux.intel.com>,
	Ross Zwisler <ross.zwisler@...ux.intel.com>,
	Rik van Riel <riel@...hat.com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Jens Axboe <axboe@...nel.dk>, Theodore Ts'o <tytso@....edu>,
	"Martin K. Petersen" <martin.petersen@...cle.com>,
	Julia Lawall <Julia.Lawall@...6.fr>, Tejun Heo <tj@...nel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	paulmck@...ux.vnet.ibm.com
Subject: Re: [PATCH v2 00/10] evacuate struct page from the block layer,
 introduce __pfn_t


* Jerome Glisse <j.glisse@...il.com> wrote:

> > So I think the main value of struct page is if everyone on the 
> > system sees the same struct page for the same pfn - not just the 
> > temporary IO instance.
> > 
> > The idea of having very temporary struct page arrays misses the 
> > point I think: if struct page is used as essentially an IO sglist 
> > then most of the synchronization properties are lost: then we 
> > might as well use the real deal in that case and skip the dynamic 
> > allocation and use pfns directly and avoid the dynamic allocation 
> > overhead.
> > 
> > Stable, global page-struct descriptors are a given for real RAM, 
> > where we allocate a struct page for every page in nice, large, 
> > mostly linear arrays.
> > 
> > We'd really need that for pmem too, to get the full power of 
> > struct page: and that means allocating them in nice, large, 
> > predictable places - such as on the device itself ...
> 
> Is handling kernel pagefault on the vmemmap completely out of the 
> picture ? So we would carveout a chunck of kernel address space for 
> those pfn and use it for vmemmap and handle pagefault on it.

That's pretty clever. The page fault doesn't even have to do remote 
TLB shootdown, because it only establishes mappings - so it's pretty 
atomic, a bit like the minor vmalloc() area faults we are doing.

Some sort of LRA (least recently allocated) scheme could unmap the 
area in chunks if it's beyond a certain size, to keep a limit on size. 
Done from the same context and would use remote TLB shootdown.

The only limitation I can see is that such faults would have to be 
able to sleep, to do the allocation. So pfn_to_page() could not be 
used in arbitrary contexts.

> Again here i think that GPU folks would like a solution where they 
> can have a page struct but it would not be PMEM just device memory. 
> So if we can come up with something generic enough to server both 
> purpose that would be better in my view.

Yes.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/