Re: [PATCH] Re: swapcache bug?

["Stephen C. Tweedie" <sct@redhat.com>]

Hi,

On Mon, 8 Feb 1999 09:32:24 -0800 (PST), Linus Torvalds
<torvalds@transmeta.com> said:

> It _may_ be that the hash function is always called with a page-aligned
> offset, but that was not how it was strictly meant to be: the way the
> thing was envisioned you could just find the page at "offset" by doing

> 	page_hash(inode,offset)

It does appear to be: we enforce it pretty much everywhere I can see,
with one possible exception: filemap_nopage(), which assumes
area->vm_offset is already page-aligned.  I think we can still violate
that internally if we are mapping a ZMAGIC binary (urgh), but the VM
breaks anyway if we do that: update_vm_cache cannot deal with such
pages, for a start.

The assumption that we might have flexible offsets will break
__find_page massively anyway, because we _always_ lookup the struct page
by exact match on the offset; __find_page never tries to align things
itself.

Linus, I know Matti Aarnio has been working on supporting >32bit offsets
on Intel, and for that we really do need to start using the low bits in
the page offset for something more useful than MBZ padding.  If there is
a long-term desire to keep those bits in the offset insignificant then
that will really hurt his work; otherwise, I can't see mixing in the
low-order bits to the page hash breaking anything new.

> If anything, maybe the swap cache should just use the high bits in the
> "offset" field 

Yes, we can certainly do that to fix the current has collision problems,
but since there are long term reasons for using more bits of
significance in the page cache offset, it would be good to know whether
you'd be willing to entertain that possibility.  If so, we'll need a
hash function which observes the low bits anyway.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/