On Thu, 5 Jul 2001, Ben LaHaise wrote:
>
> I attacked the PAGE_CACHE_SIZE support in the kernel for the last few days
> in an attempt to get multipage PAGE_CACHE_SIZE support working and below
> is what I've come up with. It currently boots to single user read only,
> doesn't quite have write support fixed properly yet, but is going pretty
> well. The reason for sending this out now is the question of what to do
> about kmap() support.
I suggest making kmap _always_ map the "biggest" chunk of physical memory
that the kernel ever touches at a time.
So I would _strongly_ suggest that you make the kmap granularity be at
_least_ PAGE_CACHE_SIZE. For debugging reasons I would suggest you have a
separate "PAGE_KMAP_SIZE" thing, so that you can get the kmap code working
independently of the PAGE_CACHE_SIZE thing.
Once you have the guarantee that "kmap(page)" will actually end up mapping
the (power-of-two-aligned) power-of-two-sized PAGE_KMAP_SIZE around the
page, the loops should all go away, and you should be able to use kmap()
the same way you've always used it (whether the user actually cares about
just one page or not ends up being a non-issue).
> - filp->f_pos = (n << PAGE_CACHE_SHIFT) | offset;
> + filp->f_pos = (n << PAGE_SHIFT) | offset;
You're definitely doing something wrong here.
You should _never_ care about PAGE_SHIFT, except in the case of a mmap()
where you obviously end up mapping in "partial" page-cache pages. I
suspect you're doing all this exactly because of the kmap issue, but you
really shouldn't need to do it.
The whole point with having a bigger page-cache-size is to be able to
process bigger chunks at a time.
Now, one thing you might actually want to look into is to make the dirty
bit be a "dirty bitmap", so that you have the option of marking things
dirty at a finer granularity. But that, I feel, is after you've gotten the
basic stuff working with a PAGE_CACHE_SIZE dirty granularity.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
