lkml.org 
[lkml]   [2008]   [Dec]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: per-cpu stats in block device: overkill?
Hello, Rusty.

Rusty Russell wrote:
> Hi Jens, Tejun, Jerome,
>
> I've been auditing alloc_per_cpu users, and got to genhd. The code
> is fairly complex, but I can't help wondering if per-cpu counters
> are overkill. After all, we have a single queue lock.

Yeah, maybe.

> The reason I care is that I'm changing alloc_per_cpu to use the
> static per-cpu area: at 40/80 bytes (32/64 bit) per stat, we'd be
> restricted to a few hundred disks unless the percpu area is enlarged
> (in current patches, a cmdline param). Or, I can change genhd to
> use big_percpu_alloc which will use the current inefficient dynamic
> per-cpu system until we get dynamic per-cpu regions (if ever).

I'm working on local counter (local_t) allocator which is used to
replace percpu allocation in percpu_counter and used as basis for
percpu_ref which replaces module ref counting and will be used to
simplify block/char lifetime rules.

The local counter allocator allocates per-cpu pages and the space
overhead is minimal. If per-cpu stats in genhd is necessary, I think
converting it to percpu local counter allocation should do it.

BTW, why make percpu area static?

Thanks.

--
tejun


\
 
 \ /
  Last update: 2008-12-22 02:59    [W:1.399 / U:0.544 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site