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
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
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
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
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
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 cache
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 a
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
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
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:
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
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
slabs
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
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
Hi again,
I recently noticed that my slub-enabled kernel won't let me stop
and restart the NFS server. It stops fine but on restart
it returns -ENOMEM.
It turns out that this is because kmem_cache_create is failing
because the name already exists in sysfs.
fs/nfsd/nfs4state creates 4
Hi again,
I recently noticed that my slub-enabled kernel won't let me stop
and restart the NFS server. It stops fine but on restart
it returns -ENOMEM.
It turns out that this is because kmem_cache_create is failing
because the name already exists in sysfs.
fs/nfsd/nfs4state creates 4
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
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 one
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 decorative
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
24 matches
Mail list logo
