Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1513880
| From | Christoph Hellwig <hch@infradead.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCHv3 15/41] filemap: handle huge pages in do_generic_file_read() |
| Date | 2016-11-02 15:40 +0100 |
| Message-ID | <sz4RP-7vs-25@gated-at.bofh.it> (permalink) |
| References | <shDuF-6vN-5@gated-at.bofh.it> <shDEn-6P5-63@gated-at.bofh.it> <srNMb-3Dq-21@gated-at.bofh.it> <syplD-5Zo-1@gated-at.bofh.it> <syKq5-2Hy-19@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Tue, Nov 01, 2016 at 05:39:40PM +0100, Jan Kara wrote: > I'd also note that having PMD-sized pages has some obvious disadvantages as > well: > > 1) I'm not sure buffer head handling code will quite scale to 512 or even > 2048 buffer_heads on a linked list referenced from a page. It may work but > I suspect the performance will suck. buffer_head handling always sucks. For the iomap based bufferd write path I plan to support a buffer_head-less mode for the block size == PAGE_SIZE case in 4.11 latest, but if I get enough other things of my plate in time even for 4.10. I think that's the right way to go for THP, especially if we require the fs to allocate the whole huge page as a single extent, similar to the DAX PMD mapping case. > 2) PMD-sized pages result in increased space & memory usage. How so? > 3) In ext4 we have to estimate how much metadata we may need to modify when > allocating blocks underlying a page in the worst case (you don't seem to > update this estimate in your patch set). With 2048 blocks underlying a page, > each possibly in a different block group, it is a lot of metadata forcing > us to reserve a large transaction (not sure if you'll be able to even > reserve such large transaction with the default journal size), which again > makes things slower. As said above I think we should only use huge page mappings if there is a single underlying extent, same as in DAX to keep the complexity down. > 4) As you have noted some places like write_begin() still depend on 4k > pages which creates a strange mix of places that use subpages and that use > head pages. Just use the iomap bufferd I/O code and all these issues will go away.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [PATCHv3 15/41] filemap: handle huge pages in do_generic_file_read() "Kirill A. Shutemov" <kirill@shutemov.name> - 2016-10-31 19:20 +0100
Re: [PATCHv3 15/41] filemap: handle huge pages in do_generic_file_read() Jan Kara <jack@suse.cz> - 2016-11-01 17:50 +0100
Re: [PATCHv3 15/41] filemap: handle huge pages in do_generic_file_read() "Kirill A. Shutemov" <kirill@shutemov.name> - 2016-11-02 09:40 +0100
Re: [PATCHv3 15/41] filemap: handle huge pages in do_generic_file_read() Christoph Hellwig <hch@infradead.org> - 2016-11-02 15:40 +0100
Re: [PATCHv3 15/41] filemap: handle huge pages in do_generic_file_read() Jan Kara <jack@suse.cz> - 2016-11-03 22:00 +0100
Re: [PATCHv3 15/41] filemap: handle huge pages in do_generic_file_read() "Kirill A. Shutemov" <kirill@shutemov.name> - 2016-11-07 12:40 +0100
Re: [PATCHv3 15/41] filemap: handle huge pages in do_generic_file_read() Christoph Hellwig <hch@infradead.org> - 2016-11-07 16:00 +0100
Re: [PATCHv3 15/41] filemap: handle huge pages in do_generic_file_read() Christoph Hellwig <hch@infradead.org> - 2016-11-02 15:40 +0100
Re: [PATCHv3 15/41] filemap: handle huge pages in do_generic_file_read() Jan Kara <jack@suse.cz> - 2016-11-03 19:00 +0100
Re: [PATCHv3 15/41] filemap: handle huge pages in do_generic_file_read() "Kirill A. Shutemov" <kirill@shutemov.name> - 2016-11-07 12:40 +0100
Re: [PATCHv3 15/41] filemap: handle huge pages in do_generic_file_read() Christoph Hellwig <hch@infradead.org> - 2016-11-07 16:30 +0100
Re: [PATCHv3 15/41] filemap: handle huge pages in do_generic_file_read() "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2016-11-07 17:10 +0100
csiph-web