[lkml]   [2002]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] [PATCH] Include LRU in page count
Daniel Phillips wrote:
> On Monday 02 September 2002 01:08, Andrew Morton wrote:
> > Daniel Phillips wrote:
> > > Note that I changed the spin_lock in page_cache_release to a trylock, maybe
> > > it's worth checking out the effect on contention. With a little head
> > > scratching we might be able to get rid of the spin_lock in lru_cache_add as
> > > well. That leaves (I think) just the two big scan loops. I've always felt
> > > it's silly to run more than one of either at the same time anyway.
> >
> > No way. Take a look at
> >
> > That's 8-way power4, the workload is "dd from 7 disks
> > dd if=/dev/sd* of=/dev/null bs=1024k".
> >
> > The CPU load in this situation was dominated by the VM. The LRU list and page
> > reclaim. Spending more CPU in lru_cache_add() than in copy_to_user() is
> > pretty gross.
> Are we looking at the same thing? The cpu load there is dominated by cpu_idle,
> 89%.

Apart from that, dummy ;) The absolute numbers are proportional
to IO bandwidth. And 7/8ths of a scsi disk per CPU isn't much.

> Anyway, if your point is that it makes sense to run shrink_cache or
> refill_inactive in parallel, I don't see it because they'll serialize on the
> lru lock anyway. What would make sense is to make shink_cache nonblocking.

Well shrink_list() runs locklessly now. But there remains a significant
cost in shrink_cache(), a little of which will be due to the hopefully-removable
page_cache_get() inside the lock.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.125 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site