From: Greg KH <gregkh@suse.de>
To: Nathan Fontenot <nfont@austin.ibm.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Andi Kleen <andi@firstfloor.org>,
linux-kernel@vger.kernel.org,
"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [PATCH] memory hotplug disable boot option
Date: Mon, 28 Jun 2010 08:44:55 -0700 [thread overview]
Message-ID: <20100628154455.GA13918@suse.de> (raw)
In-Reply-To: <4C28C1A8.8010904@austin.ibm.com>
On Mon, Jun 28, 2010 at 10:37:12AM -0500, Nathan Fontenot wrote:
> On 06/28/2010 10:02 AM, Greg KH wrote:
> > On Mon, Jun 28, 2010 at 11:20:27AM +0900, KOSAKI Motohiro wrote:
> >>> On 06/25/2010 04:19 AM, Andi Kleen wrote:
> >>>> KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> writes:
> >>>>
> >>>>>> Proposed patch to disable memory hotplug via a boot option,
> >>>>>> mem_hotplug=[on|off]. The patch only disables memory hotplug in that it
> >>>>>> prevents the creation of the memory sysfs directories for memory sections.
> >>>>>>
> >>>>>> This patch is meant to help alleviate very long boot times on systems with
> >>>>>> large memory (1+ TB) and many memory sections (10's of thousands).
> >>>>>
> >>>>> Why making simple /sys file is so slowly? Couldn't we fix such performance
> >>>>> problem?
> >>>
> >>> The issue is the large number of sysfs memory directories that get created.
> >>> On a system with 1 TB of memory I am seeing ~63,00 directories. The long
> >>> creation time is due to the string compare check in sysfs code to ensure
> >>> we are not creating a directory with a duplicate name.
> >>
> >> Ah, I see. probably this is sysfs issue. So Let's cc Greg and Eric.
> >> Greg, I have dumb question. Why sysfs call strcmp() so heavily? I mean why sysfs
> >> don't have hash based name dupliation check?
> >
> > Because we have not needed such complexity before.
> >
> > You might want to take a step back and asky why you are creating 63
> > thousand directories in sysfs for large memory systems. Are you really
> > going to use all of those directories? What are they for? Perhaps
> > someone created the wrong interface to memory and that needs to be fixed
> > instead?
> >
>
> The directories being created are the standard directories, one for each of the memory
> sections present at boot. I think the most used files in each of these directories
> is the state and removable file used to do memory hotplug.
And perhaps we shouldn't really be creating so many directories? Why
not work with the memory hotplug developers to change their interface to
not abuse sysfs in such a manner?
thanks,
greg k-h
next prev parent reply other threads:[~2010-06-28 15:50 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-25 1:06 [PATCH] memory hotplug disable boot option Nathan Fontenot
2010-06-25 2:04 ` KOSAKI Motohiro
2010-06-25 9:19 ` Andi Kleen
2010-06-25 14:51 ` Nathan Fontenot
2010-06-25 14:56 ` Andi Kleen
2010-06-25 15:21 ` Nathan Fontenot
2010-06-25 15:28 ` Andi Kleen
2010-06-25 16:00 ` Nathan Fontenot
2010-06-28 2:20 ` KOSAKI Motohiro
2010-06-28 4:15 ` Eric W. Biederman
2010-06-28 14:16 ` Andi Kleen
2010-06-28 19:43 ` Eric W. Biederman
2010-06-28 15:02 ` Greg KH
2010-06-28 15:37 ` Nathan Fontenot
2010-06-28 15:44 ` Greg KH [this message]
2010-06-29 0:04 ` Dave Hansen
2010-06-29 2:56 ` KOSAKI Motohiro
2010-06-29 15:38 ` Nathan Fontenot
2010-06-30 0:00 ` KOSAKI Motohiro
2010-06-29 16:03 ` Dave Hansen
2010-06-29 18:04 ` Greg KH
2010-06-30 0:32 ` KAMEZAWA Hiroyuki
2010-06-30 15:47 ` Greg KH
2010-07-01 0:31 ` KAMEZAWA Hiroyuki
2010-07-01 3:17 ` Nathan Fontenot
2010-07-01 3:30 ` KAMEZAWA Hiroyuki
2010-07-01 23:28 ` Greg KH
2010-07-01 5:15 ` KAMEZAWA Hiroyuki
2010-07-01 13:23 ` Dave Hansen
2010-07-06 15:20 ` Nathan Fontenot
2010-07-06 15:33 ` Dave Hansen
2010-07-06 15:47 ` Nathan Fontenot
2010-07-01 23:26 ` Greg KH
2010-07-02 5:50 ` KAMEZAWA Hiroyuki
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=20100628154455.GA13918@suse.de \
--to=gregkh@suse.de \
--cc=andi@firstfloor.org \
--cc=ebiederm@xmission.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nfont@austin.ibm.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