linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Nadia Derbey <Nadia.Derbey@bull.net>
To: Yasunori Goto <y-goto@jp.fujitsu.com>
Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
	linux-mm@kvack.org, containers@lists.linux-foundation.org,
	matthltc@us.ibm.com
Subject: Re: [RFC][PATCH v2 7/7] Do not recompute msgmni anymore if explicitely set by user
Date: Tue, 05 Feb 2008 15:55:10 +0100	[thread overview]
Message-ID: <47A878CE.1060304@bull.net> (raw)
In-Reply-To: <20080205222005.67FE.Y-GOTO@jp.fujitsu.com>

Yasunori Goto wrote:
> Thanks Nadia-san.
> 
> I tested this patch set on my box. It works well.
> I have only one comment.
> 
> 
> 
>>---
>> ipc/ipc_sysctl.c |   43 +++++++++++++++++++++++++++++++++++++++++--
>> 1 file changed, 41 insertions(+), 2 deletions(-)
>>
>>Index: linux-2.6.24/ipc/ipc_sysctl.c
>>===================================================================
>>--- linux-2.6.24.orig/ipc/ipc_sysctl.c	2008-01-29 16:55:04.000000000 +0100
>>+++ linux-2.6.24/ipc/ipc_sysctl.c	2008-01-31 13:13:14.000000000 +0100
>>@@ -34,6 +34,24 @@ static int proc_ipc_dointvec(ctl_table *
>> 	return proc_dointvec(&ipc_table, write, filp, buffer, lenp, ppos);
>> }
>> 
>>+static int proc_ipc_callback_dointvec(ctl_table *table, int write,
>>+	struct file *filp, void __user *buffer, size_t *lenp, loff_t *ppos)
>>+{
>>+	size_t lenp_bef = *lenp;
>>+	int rc;
>>+
>>+	rc = proc_ipc_dointvec(table, write, filp, buffer, lenp, ppos);
>>+
>>+	if (write && !rc && lenp_bef == *lenp)
>>+		/*
>>+		 * Tunable has successfully been changed from userland:
>>+		 * disable its automatic recomputing.
>>+		 */
>>+		unregister_ipcns_notifier(current->nsproxy->ipc_ns);
>>+
>>+	return rc;
>>+}
>>+
> 
> 
> 
> Hmmm. I suppose this may be side effect which user does not wish.
> 
> I would like to recommend there should be a switch which can turn on/off
> automatic recomputing.
> If user would like to change this value, it should be turned off.
> Otherwise, his requrest will be rejected with some messages.
> 
> Probably, user can understand easier than this side effect.
> 

Hi Yasunori,

Hope you're feeling better!

Well the idea behind this was the following: if msgmni is changed say 
via procfs it is usually to increase it, in order for applications that 
need more msg queues to be able to run.
So even if a new ipc namespace is created or memory is removed, the 
application that has set that new value doesn't care: it wants msgmni to 
be unchanged. I agree with you that unconditionally turning the 
recomputing off may appear coarse, but I'm afraid that adding the 
functionality of turning that recomputing on/off will make things more 
complicated:
1) manage the tunable recomputing state: it shouldn't be turned on twice
2) adds more things to do at the user level.

I'll try to think about it more deeply and may be come up with an 
intermediate solution.

Regards,
Nadia



--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

      reply	other threads:[~2008-02-05 14:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-31 13:40 [RFC][PATCH v2 0/7] Scaling msgmni to the amount of lowmem Nadia.Derbey
2008-01-31 13:40 ` [RFC][PATCH v2 1/7] " Nadia.Derbey
2008-01-31 13:40 ` [RFC][PATCH v2 2/7] Scaling msgmni to the number of ipc namespaces Nadia.Derbey
2008-01-31 13:40 ` [RFC][PATCH v2 3/7] Defining the slab_memory_callback priority as a constant Nadia.Derbey
2008-01-31 13:40 ` [RFC][PATCH v2 4/7] Recomputing msgmni on memory add / remove Nadia.Derbey
2008-01-31 13:40 ` [RFC][PATCH v2 5/7] Invoke the ipcns notifier chain as a work item Nadia.Derbey
2008-01-31 13:40 ` [RFC][PATCH v2 6/7] Recomputing msgmni on ipc namespace creation/removal Nadia.Derbey
2008-01-31 13:40 ` [RFC][PATCH v2 7/7] Do not recompute msgmni anymore if explicitely set by user Nadia.Derbey
2008-02-05 13:38   ` Yasunori Goto
2008-02-05 14:55     ` Nadia Derbey [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47A878CE.1060304@bull.net \
    --to=nadia.derbey@bull.net \
    --cc=akpm@linux-foundation.org \
    --cc=containers@lists.linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=matthltc@us.ibm.com \
    --cc=y-goto@jp.fujitsu.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).