All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Matti Aarnio <matti.aarnio@sonera.fi>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: sct@redhat.com, masp0008@stud.uni-sb.de, linux-mm@kvack.org
Subject: Re: [PATCH] Re: swapcache bug?
Date: Mon, 8 Feb 1999 23:13:55 +0200 (EET)	[thread overview]
Message-ID: <19990208211402Z92298-868+220@mea.tmt.tele.fi> (raw)
In-Reply-To: <Pine.LNX.3.95.990208104249.606M-100000@penguin.transmeta.com> from Linus Torvalds at "Feb 8, 99 10:48:06 am"

Linus Torvalds <torvalds@transmeta.com> wrote:
...
> > 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. 

	I forgot (didn't log), who sent me a patch to my L-F-S stuff
	for ZMAGIC page mis-alignment report.  (It was somebody here
	at linux-mm list)  His comment was that only *very old* systems
	contain ZMAGIC files with alignments not already in page
	granularity.

	Given certain limitations in low-level block drivers, using that
	'sector index' idea might be worthy.  It gives us essentially up
	to 512 * 4GB or 2 TB file sizes, which matches current low-level
	limitations.

	However, now doing page offset work, we might need to mask the low
	bits of the sector index to do page cache searches.  (Unless the
	alignment is always guaranteed ?)

> 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.

	Good heavens! No!  That can't have been mine.

	In my patches the 'page->offset' became ADT called 'pgoff_t'
	which I used to do compile time trapping of missing convertions.
	When simplified ("#if 1" -> "#if 0" in <linux/mm.h> header file),
	the type is just 'u_long'.

	I don't think you have seen my patches, I have posted the URL,
	but not the patches themselves.

	With recent talks in linux-kernel about internal VFS ABI stability
	being an issue, my current L-F-S patch is *not* ready for 2.2.*.
	It changes one thing, and adds another in the inode_operations
	structure, plus adds a field into 'struct task'.

	I would wait a bit until 2.3 opens, collect a bit of experience
	of it there, and then backport (without doing VFS ABI changes) to
	2.2.*.    Otherwise: "Damn the torpedoes!  Full steam ahead!".
	(And we would hear lots of noicy torpedoes...)

... 
> 		Linus

/Matti Aarnio <matti.aarnio@sonera.fi>
--
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/

  reply	other threads:[~1999-02-08 21:14 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
1999-02-08 21:13         ` Matti Aarnio [this message]
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=19990208211402Z92298-868+220@mea.tmt.tele.fi \
    --to=matti.aarnio@sonera.fi \
    --cc=linux-mm@kvack.org \
    --cc=masp0008@stud.uni-sb.de \
    --cc=sct@redhat.com \
    --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.