lkml.org 
[lkml]   [2003]   [May]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] kmalloc_percpu
On Mon, May 05 2003, Andrew Morton wrote:
> "David S. Miller" <davem@redhat.com> wrote:
> >
> > From: Andrew Morton <akpm@digeo.com>
> > Date: Mon, 5 May 2003 23:42:48 -0700
> >
> > Can't think of anything very clever there, except to go and un-percpuify the
> > disk stats. I think that's best, really - disk requests only come in at 100
> > to 200 per second - atomic_t's or int-plus-per-disk-spinlock will be fine.
> >
> > Use some spinlock we already have to be holding during the
> > counter bumps.
>
> Last time we looked at that, q->lock was already held in almost all the right
> places so yes, that'd work.

As far as I can see, queue lock _is_ held in all the right spot. At
least where it matters, adding new samples.

> > Frankly, these things don't need to be %100 accurate. Using
> > a new spinlock or an atomic_t for this seems rediculious.
>
> The disk_stats structure has an "in flight" member. If we don't have proper
> locking around that, disks will appear to have -3 requests in flight for all
> time, which would look a tad odd.

So check for < 0 in flight? I totally agree with davem here.

--
Jens Axboe

-
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: 2005-03-22 13:35    [W:0.079 / U:0.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site