On Tue, 24 Apr 2007, Neil Brown wrote:
> kobject_set_name actually takes a format and arbitrary args and uses
> vsnprintf, so it has to make it's own copy.
Ok then this should be fine...
SLAB: Fix sysfs directory handling
This fixes the problem that SLUB does not track the names of aliased
slab
On Monday April 23, [EMAIL PROTECTED] wrote:
> On Tue, 24 Apr 2007, Neil Brown wrote:
>
> > On Monday April 23, [EMAIL PROTECTED] wrote:
> > > Would this work? Contains a solution somewhat along the lines of your
> > > thoughts on the subject.
> > >
> >
> > Concept seems sound.
> > Code needs a
On Tue, 24 Apr 2007, Neil Brown wrote:
> On Monday April 23, [EMAIL PROTECTED] wrote:
> > Would this work? Contains a solution somewhat along the lines of your
> > thoughts on the subject.
> >
>
> Concept seems sound.
> Code needs a kfree of the name returned by create_unique_id, and I
> think
On Monday April 23, [EMAIL PROTECTED] wrote:
> Would this work? Contains a solution somewhat along the lines of your
> thoughts on the subject.
>
Concept seems sound.
Code needs a kfree of the name returned by create_unique_id, and I
think ID_STR_LENGTH needs to be at least 34.
Maybe that should
Would this work? Contains a solution somewhat along the lines of your
thoughts on the subject.
SLAB: Fix sysfs directory handling
This fixes the problem that SLUB does not track the names of aliased
slabs by changing the way that SLUB manages the files in /sys/slab.
If the slab that is being c
On Mon, 23 Apr 2007, Neil Brown wrote:
> Another option might be to name each cache actually created with a
> unique name, and then create a symlink for each cache that was asked
> for (whether it was created or whether a pre-existing cache was used).
> Then being lazy about deletion shouldn't be
On Thursday April 19, [EMAIL PROTECTED] wrote:
>
> Right. Sigh. But there is no user of the symlinks.
>
> I could drop the symlinks completely. Just do not track what names a cache
> aliases to?
>
Suppose I have a kmem_cache which at different times has different
sizes (like, for example, the
Another approach drop the symlinks completely. Just
write a message to the syslog informing the user that we
created an alias. If debugging is off then the user would have to consult
the syslog to find aliases.
Index: linux-2.6.21-rc6/mm/slub.c
===
On Fri, 20 Apr 2007, Neil Brown wrote:
> On Thursday April 19, [EMAIL PROTECTED] wrote:
> > On Fri, 20 Apr 2007, Neil Brown wrote:
> >
> > > Not sure how best to fix this one kmem_cache_destroy currently
> > > doesn't know which alias is being destroyed.
> >
> > The aliases are there for dec
On Thursday April 19, [EMAIL PROTECTED] wrote:
> On Fri, 20 Apr 2007, Neil Brown wrote:
>
> > Not sure how best to fix this one kmem_cache_destroy currently
> > doesn't know which alias is being destroyed.
>
> The aliases are there for decorative purposes when running without
> debugging. If
On Fri, 20 Apr 2007, Neil Brown wrote:
> Not sure how best to fix this one kmem_cache_destroy currently
> doesn't know which alias is being destroyed.
The aliases are there for decorative purposes when running without
debugging. If one switches on debugging then it matters but then the
symlin
On Thu, 12 Apr 2007, Neil Brown wrote:
> And
>
> # cat /sys/slab/raid5-md1/aliases
> -1
>
> is a bit suspicious.
Yuck!
> void kmem_cache_destroy(struct kmem_cache *s)
> {
> down_write(&slub_lock);
> if (s->refcount)
> s->refcount--;
> else {
>
12 matches
Mail list logo
