From: Jakub Jelinek <jj@sunsite.ms.mff.cuni.cz>
To: "Eric W. Biederman" <ebiederm+eric@ccr.net>
Cc: Linus Torvalds <torvalds@transmeta.com>,
linux-kernel@vger.rutgers.edu, linux-mm@kvack.org
Subject: Re: [PATCH] cache large files in the page cache
Date: Wed, 26 May 1999 09:44:07 +0200 [thread overview]
Message-ID: <19990526094407.J527@mff.cuni.cz> (raw)
In-Reply-To: <m17lpzsi0h.fsf@flinx.ccr.net>; from Eric W. Biederman on Sun, May 23, 1999 at 02:28:14PM -0500
> Details:
>
> This patch replaces vm_offset with vm_index, with the relationship:
> vm_offset == (vm_index << PAGE_SHIFT). Except vm_index can hold larger
> offsets.
I have minor suggestion to the patch. Instead of using vm_index <<
PAGE_SHIFT and page->key << PAGE_CACHE_SHIFT shifts either choose different
constant names for this shifting (VM_INDEX_SHIFT and PAGE_KEY_SHIFT) or hide
these shifts by some pretty macros (you'll need two for each for both
directions in that case - if you go the macro way, maybe it would be a good
idea to make vm_index and key type some structure with a single member like
mm_segment_t for more strict typechecking). This would have the advantage of
avoiding shifting on 64bit archs, where it really is not necessary as no
filesystem will support 16000EB filesizes in the near future. I know shifts
are not expensive, on the other side count how many there will be and IMHO
it should be considered. It could make the code more readable at the same
time. VM_INDEX_SHIFT would be defined to 0 on alpha,sparc64
(merced,mips64,ppc64) and PAGE_SHIFT on other platforms. The same with
PAGE_KEY_SHIFT.
Cheers,
Jakub
___________________________________________________________________
Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz
Administrator of SunSITE Czech Republic, MFF, Charles University
___________________________________________________________________
UltraLinux | http://ultra.linux.cz/ | http://ultra.penguin.cz/
Linux version 2.3.3 on a sparc64 machine (1343.49 BogoMips)
___________________________________________________________________
--
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-05-26 7:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-05-23 19:28 Eric W. Biederman
1999-05-24 15:27 ` Andrea Arcangeli
1999-05-26 7:44 ` Jakub Jelinek [this message]
1999-05-26 17:44 ` Linus Torvalds
1999-05-30 17:17 ` Eric W. Biederman
1999-05-30 17:47 ` Linus Torvalds
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=19990526094407.J527@mff.cuni.cz \
--to=jj@sunsite.ms.mff.cuni.cz \
--cc=ebiederm+eric@ccr.net \
--cc=linux-kernel@vger.rutgers.edu \
--cc=linux-mm@kvack.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox