From: "Stephen C. Tweedie" <sct@redhat.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: "Stephen C. Tweedie" <sct@redhat.com>,
masp0008@stud.uni-sb.de,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [PATCH] Re: swapcache bug?
Date: Mon, 8 Feb 1999 17:51:36 GMT [thread overview]
Message-ID: <199902081751.RAA03584@dax.scot.redhat.com> (raw)
In-Reply-To: <Pine.LNX.3.95.990208092701.31153B-100000@penguin.transmeta.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/
next prev parent reply other threads:[~1999-02-07 22:46 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-02-07 18:21 swapcache bug? Manfred Spraul
1999-02-07 21:30 ` Eric W. Biederman
1999-02-08 16:39 ` [PATCH] " Stephen C. Tweedie
1999-02-08 17:32 ` Linus Torvalds
1999-02-08 17:51 ` Stephen C. Tweedie [this message]
1999-02-08 18:48 ` Linus Torvalds
1999-02-08 21:13 ` Matti Aarnio
1999-02-09 7:15 ` Eric W. Biederman
1999-02-09 16:32 ` Linus Torvalds
1999-02-10 0:28 ` Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199902081751.RAA03584@dax.scot.redhat.com \
--to=sct@redhat.com \
--cc=linux-mm@kvack.org \
--cc=masp0008@stud.uni-sb.de \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.