lkml.org 
[lkml]   [2007]   [Sep]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [00/41] Large Blocksize Support V7 (adds memmap support)
On Tue, 11 Sep 2007, Nick Piggin wrote:

> But that's not my place to say, and I'm actually not arguing that high
> order pagecache does not have uses (especially as a practical,
> shorter-term solution which is unintrusive to filesystems).
>
> So no, I don't think I'm really going against the basics of what we agreed
> in Cambridge. But it sounds like it's still being billed as first-order
> support right off the bat here.

Well its seems that we have different interpretations of what was agreed
on. My understanding was that the large blocksize patchset was okay
provided that I supply an acceptable mmap implementation and put a
warning in.

> But even so, you can just hold an open fd in order to pin the dentry you
> want. My attack would go like this: get the page size and allocation group
> size for the machine, then get the number of dentries required to fill a
> slab. Then read in that many dentries and pin one of them. Repeat the
> process. Even if there is other activity on the system, it seems possible
> that such a thing will cause some headaches after not too long a time.
> Some sources of pinned memory are going to be better than others for
> this of course, so yeah maybe pagetables will be a bit easier (I don't know).

Well even without slab targeted reclaim: Mel's antifrag will sort the
dentries into separate blocks of memory and so isolate the issue.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-09-11 23:51    [W:0.144 / U:0.748 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site