On Fri, 26 Jan 2007 10:23:44 -0800 (PST) Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Fri, 26 Jan 2007, Andrew Morton wrote: > > > > Large amounts of mlocked pages may be a problem for > > > > > > 1. Reclaim behavior. > > > > > > 2. Defragmentation > > > > > > > We know that. What has that to do with this patch? > > Knowing how much mlocked pages are where is necessary to solve these > issues. If we continue this dialogue for long enough, we'll actually have a changlog. > > > > You could perhaps go for a walk across all the other vmas which > > > > presently > > > > map this page. If any of them have VM_LOCKED, don't increment the > > > > counter. > > > > Similar on removal: only decrement the counter when the final mlocked > > > > VMA > > > > is dropping the pte. > > > > > > For that we would need an additional refcount for vmlocked maps in the > > > page struct. > > > > No you don't. The refcount is already there. It is "the sum of the > > VM_LOCKED > > VMAs which map this page". > > > > It might be impractical or expensive to calculate it, but it's there. > > Correct. Its so expensive that it cannot be used to build vm stats for > mlocked pages. F.e. Determination of the final mlocked VMA dropping the > page would require a scan over all vmas mapping the page. Of course it would. But how do you know it is "too expensive"? We "scan all the vmas mapping a page" as a matter of course in the page scanner - millions of times a minute. If that's "too expensive" then ouch. That, plus if we have so many vmas mapping a page for this effect to matter, then your change as proposed will be so inaccurate as to be useless, no? - 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/
