On Fri, Jan 31, 2014 at 04:19:43PM -0800, Dave Hansen wrote: > On 01/31/2014 03:27 PM, James Bottomley wrote: > > On Fri, 2014-01-31 at 13:47 -0800, Dave Hansen wrote: > >> On 01/31/2014 11:02 AM, James Bottomley wrote: > >>> 3. Increase pgoff_t and the radix tree indexes to u64 for > >>> CONFIG_LBDAF. This will blow out the size of struct page on 32 > >>> bits by 4 bytes and may have other knock on effects, but at > >>> least it will be transparent. > >> > >> I'm not sure how many acrobatics we want to go through for 32-bit, but... > > > > That's partly the question: 32 bits was dying in the x86 space (at least > > until quark), but it's still predominant in embedded. > > > >> Between page->mapping and page->index, we have 64 bits of space, which > >> *should* be plenty to uniquely identify a block. We could easily add a > >> second-level lookup somewhere so that we store some cookie for the > >> address_space instead of a direct pointer. How many devices would need, > >> practically? 8 bits worth? > > > > That might work. 8 bits would get us up to 4PB, which is looking a bit > > high for single disk spinning rust. However, how would the cookie work > > efficiently? remember we'll be doing this lookup every time we pull a > > page out of the page cache. And the problem is that most of our lookups > > will be on file inodes, which won't be > 16TB, so it's a lot of overhead > > in the generic machinery for a problem that only occurs on buffer > > related page cache lookups. > > I think all we have to do is set a low bit in page->mapping It's already in use to say page->mapping is anon_vma. ;) -- Kirill A. Shutemov -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>