On Fri, 21 Sep 2007, Andrew Morton wrote:
>
> On Fri, 21 Sep 2007 13:39:06 +0400
> Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
>
> > Quite a few fields are zeroed during user_struct creation, so use
> > kmem_cache_zalloc() -- save a few lines and #ifdef. Also will help avoid
> > #ifdef CONFIG_
Pavel Emelyanov wrote:
> Long time ago we decided to start memory control with the
> user memory container. Now this container in -mm tree and
> I think we can start with (at least discussion of) the
> kmem one.
>
Hi, Pavel,
Yes, I remember the entire discussion. Also in the TODO
list is an mloc
On Fri, 21 Sep 2007 13:39:06 +0400
Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
> Quite a few fields are zeroed during user_struct creation, so use
> kmem_cache_zalloc() -- save a few lines and #ifdef. Also will help avoid
> #ifdef CONFIG_POSIX_MQUEUE in next patch.
>
> Signed-off-by: Alexey Dobr
On Fri, 21 Sep 2007 17:35:43 +0400 Andrey Mirkin wrote:
> From: Andrey Mirkin <[EMAIL PROTECTED]>
>
> Right now futexfs and inotifyfs have one magic 0xBAD1DEA, that looks a little
> bit confusing.
> Use 0xBAD1DEA as magic for futexfs and 0x2BAD1DEA as magic for inotifyfs.
>
> Signed-off-by: And
On Thu, Sep 20, 2007 at 10:03:59PM -0700, [EMAIL PROTECTED] wrote:
> Matt Mackall [EMAIL PROTECTED] wrote:
> | On Wed, Sep 19, 2007 at 05:16:44PM -0700, [EMAIL PROTECTED] wrote:
> | > Matt,
> | >
> | > The pid-namespace patcheset (http://lkml.org/lkml/2007/8/10/118)
> | > was added to the -mm tree
On the Friday 21 September 2007 16:37 Trond Myklebust, wrote:
> On Fri, 2007-09-21 at 13:13 +0400, Vitaliy Gusev wrote:
> > Hello.
> >
> > Tested kernels: 2.6.18, 2.6.22, 2.6.23-rc2
> >
> > Steps to reproduce: Suppose that we have mounted some directory from nfs
> > v3 server with default options.
From: Andrey Mirkin <[EMAIL PROTECTED]>
Right now futexfs and inotifyfs have one magic 0xBAD1DEA, that looks a little
bit confusing.
Use 0xBAD1DEA as magic for futexfs and 0x2BAD1DEA as magic for inotifyfs.
Signed-off-by: Andrey Mirkin <[EMAIL PROTECTED]>
diff --git a/fs/inotify_user.c b/
On Fri, 2007-09-21 at 13:13 +0400, Vitaliy Gusev wrote:
> Hello.
>
> Tested kernels: 2.6.18, 2.6.22, 2.6.23-rc2
>
> Steps to reproduce: Suppose that we have mounted some directory from nfs v3
> server with default options. Also we have the two directories in this
> mountpoint and each director
On 20.09.2007 11:13, Pavel Emelyanov wrote:
> [EMAIL PROTECTED] wrote:
>>
>> The pid-namespace patcheset (http://lkml.org/lkml/2007/8/10/118)
>> was added to the -mm tree in 2.6.23-rc3-mm1.
>>
>> With CONFIG_CC_OPTIMIZE_FOR_SIZE=y this patchset increases the kernel
>> text size by about 5K (closer
Hello.
Tested kernels: 2.6.18, 2.6.22, 2.6.23-rc2
Steps to reproduce: Suppose that we have mounted some directory from nfs v3
server with default options. Also we have the two directories in this
mountpoint and each directory has hard linked file. Try to open those files
and write to one and
Hello Alexey !
Alexey Dobriyan wrote:
> for those who deselect POSIX message queues.
>
> Reduces SLAB size of user_struct from 64 to 32 bytes here,
> SLUB size -- from 40 bytes to 32 bytes.
>
> Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
> ---
>
> include/linux/sched.h |2 ++
> kern
Quite a few fields are zeroed during user_struct creation, so use
kmem_cache_zalloc() -- save a few lines and #ifdef. Also will help avoid
#ifdef CONFIG_POSIX_MQUEUE in next patch.
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
kernel/user.c | 13 +
1 file changed, 1 inse
for those who deselect POSIX message queues.
Reduces SLAB size of user_struct from 64 to 32 bytes here,
SLUB size -- from 40 bytes to 32 bytes.
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
include/linux/sched.h |2 ++
kernel/user.c |2 --
2 files changed, 2 insertions(
Save some space because uid_hash_find() has 3 callsites.
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
kernel/user.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
--- a/kernel/user.c
+++ b/kernel/user.c
@@ -55,17 +55,17 @@ struct user_struct root_user = {
/*
* Thes
The struct page gets an extra pointer (just like it has with
the RSS controller) and this pointer points to the array of
the kmem_container pointers - one for each object stored on
that page itself.
Thus the i'th object on the page is accounted to the container
pointed by the i'th pointer on that
Attach the controller to the containers. This will work
with the SLUB allocator only. However, if we need I can
port this on SLAB (and maybe SLOB ;) ).
This setup is simple and stupid.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
diff --git a/include/linux/container_subsys.h b/include
The /sys/slab//cache_notify attribute controls
whether the cache is to be accounted or not.
For the reasons described before kmalloc caches cannot
be turned on.
By default no caches are accountable. Simply make
# echo -n 1 > /sys/slab/cache_notify
to turn notification of this cache on.
If we
If the user wants more than one listener for SLUB event,
it can register them all as notifier_block-s so all of
them will be notified.
This costs us about 10% of performance loss, in comparison
with static linking.
The selected method of notification is srcu notifier blocks.
This is selected beca
According to Christoph, there are already multiple people who
want to control slab allocations and track memory for various
reasons. So this is an introduction of such a hooks.
Currently, functions that are to call the notifiers are empty
and marked as "weak". Thus, if there's only _one_ listene
Eric W. Biederman wrote:
"Denis V. Lunev" <[EMAIL PROTECTED]> writes:
Daniel Lezcano wrote:
This place is a very tricky, indeed. If we keep the namespace until
timewait bucket death - we'll keep the namespace alive at least 5
_minutes_ after all process death.
Yes, that's right. And for me th
Long time ago we decided to start memory control with the
user memory container. Now this container in -mm tree and
I think we can start with (at least discussion of) the
kmem one.
Changes since v.3:
* moved alloc/free notification into slow path and make
"notify-able" caches walk this path alwa
I'm terribly sorry :(. The v3 was already sent, so this must be v4.
The whole thread will be resent.
Sorry,
Pavel
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
Long time ago we decided to start memory control with the
user memory container. Now this container in -mm tree and
I think we can start with (at least discussion of) the
kmem one.
Changes since v.2:
* moved alloc/free notification into slow path and make
"notify-able" caches walk this path alwa
"Denis V. Lunev" <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> Ok. I have found an important case. loopback.
> May be it will be better to move this in netdev_run_todo to cleanup
> locking. I am not sure right now.
? register_netdev when we create a new loopback device.
> Basicall
Eric W. Biederman wrote:
> "Denis V. Lunev" <[EMAIL PROTECTED]> writes:
>
>> Hello, Eric!
>>
>> Current locking in mainstream seems broken to me.
>
> Thanks. After looking at this I concur.
>
>> 1. struct net->list is manipulated under double net_mutex/net_list_mutex
>
> Yes. Making iteration
"Denis V. Lunev" <[EMAIL PROTECTED]> writes:
> Hello, Eric!
>
> Current locking in mainstream seems broken to me.
Thanks. After looking at this I concur.
> 1. struct net->list is manipulated under double net_mutex/net_list_mutex
Yes. Making iteration safe if we hold only one of those.
> 2. n
J. Bruce Fields wrote:
> On Thu, Sep 20, 2007 at 01:09:51PM +0400, Pavel Emelyanov wrote:
>> J. Bruce Fields wrote:
>>> On Tue, Sep 18, 2007 at 05:41:08PM +0400, Pavel Emelyanov wrote:
This is the next step in fs/locks.c cleanup before turning
it into using the struct pid *.
Th
27 matches
Mail list logo
