From: Linus Torvalds <torvalds@transmeta.com>
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: masp0008@stud.uni-sb.de, "linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [PATCH] Re: swapcache bug?
Date: Mon, 8 Feb 1999 10:48:06 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.3.95.990208104249.606M-100000@penguin.transmeta.com> (raw)
In-Reply-To: <199902081751.RAA03584@dax.scot.redhat.com>
On Mon, 8 Feb 1999, Stephen C. Tweedie wrote:
>
> 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.
This was done on purpose: it still works as a mapping, but it isn't
coherent with regards to writes to the file. That's fine, as writing to an
executable while it has been mapped is a losing proposition anyway, and
you can't get access through these non-page-aligned mappings any other way
(the "mmap()" system calls etc will all enforce page-aligned regions,
because coherency just wouldn't be possible otherwise).
> 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.
Good point.
> 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.
Yes. The page offset will become a "sector offset" (I'd actually like to
make it a page number, but then I'd have to break ZMAGIC dynamic loading
due to the fractional page offsets, so it's not worth it for three extra
bits), and that gives you 41 bits of addressing even on a 32-bit machine.
Which is plenty - considering that by the time you need more than that
you'd _really_ better be running on a larger machine anyway.
Note that some patches I saw (I think by Matti) made "page->offset" a long
long, and that is never going to happen. That's just a stupid waste of
time and memory.
> 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.
Ok, you convinced me.
Linus
--
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-08 18:48 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
1999-02-08 18:48 ` Linus Torvalds [this message]
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=Pine.LNX.3.95.990208104249.606M-100000@penguin.transmeta.com \
--to=torvalds@transmeta.com \
--cc=linux-mm@kvack.org \
--cc=masp0008@stud.uni-sb.de \
--cc=sct@redhat.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.