Messages in this thread | | | Date | Tue, 6 May 2003 09:25:00 +0200 | From | Jens Axboe <> | Subject | Re: [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/
| |