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-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
