linux-kernel - Re: linux-next: build failure after merge of the driver-core tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100324123723.43d24a42@notabene.brown>
Date:	Wed, 24 Mar 2010 12:37:23 +1100
From:	Neil Brown <neilb@...e.de>
To:	Sage Weil <sage@...dream.net>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>, Greg KH <greg@...ah.com>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: linux-next: build failure after merge of the driver-core tree

On Wed, 17 Mar 2010 08:51:49 -0700 (PDT)
Sage Weil <sage@...dream.net> wrote:

> > It is a pity that this code cannot use mempool_t....
> > What if mempool_t were changed to only re-alloc the vector of pointers when
> > it grew, or when it shrank to less than 1/2 it's current size.  Would that
> > reduce the frequency of allocations enough for you to be comfortable with it? 
> > i.e. always make the vector a power-of-2 size (which is what is probably
> > allocated anyway) while the pool size might be less.
> > ??
> 
> That would improve the situation, but still mean potentially large 
> allocations (the pools can grow pretty big) that aren't strictly 
> necessary.  I can imagine a more modular mempool_t with an ops vector for 
> adding/removing from the pool to cope with situations like this, but I'm 
> not sure it's worth the effort?

How big?
mempools (and equivalents) should just be large enough to get you through a
tight spot.  The working assumption is that they will not normally be used.
So 2 or 3 should normally be plenty.

(looks at code)

The only time you resize a ceph_mempool is in ceph_monc_do_statfs
where you increment it, perform a synchronous statfs call on the 
network, then decrement the size of the mempool.
How many concurrent statfs calls does it even make sense to make.
I'm probably missing something obvious, but wouldn't it make sense to
put that all under a mutex so there was only ever one outstanding statfs (per
filesystem) - or maybe under a counting semaphore to allow some small number,
and make sure to prime the mempool to cover that number.
Then you would never resize a mempool at all.

I notice that all other mempools that ceph uses are sensibly quite small and
stay that way.

NeilBrown
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/