All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Jones <davej@redhat.com>
To: Nathan Zimmer <nzimmer@sgi.com>
Cc: Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC 2/2] procfs: /proc/sched_debug fails on very very large machines.
Date: Tue, 6 Nov 2012 18:49:49 -0500	[thread overview]
Message-ID: <20121106234949.GA24258@redhat.com> (raw)
In-Reply-To: <20121106232414.GA7338@gulag1.americas.sgi.com>

On Tue, Nov 06, 2012 at 05:24:15PM -0600, Nathan Zimmer wrote:
 > On Tue, Nov 06, 2012 at 04:31:28PM -0500, Dave Jones wrote:
 > > On Tue, Nov 06, 2012 at 03:02:21PM -0600, Nathan Zimmer wrote:
 > >  > On systems with 4096 cores attemping to read /proc/sched_debug fails.
 > >  > We are trying to push all the data into a single kmalloc buffer.
 > >  > The issue is on these very large machines all the data will not fit in 4mb.
 > >  > 
 > >  > A better solution is to not us the single_open mechanism but to provide
 > >  > our own seq_operations and treat each cpu as an individual record.
 > > 
 > > Good timing.
 > > 
 > > This looks like it would solve the problem I just reported here:
 > > https://lkml.org/lkml/2012/11/6/390
 > > 
 > > That happens even on an 8-way, so it's not just niche machines that have
 > > this problems.
 > 
 > Glad to help. I hadn't thought of memory tight situation but it does make sense
 > that it helps as it can get by with 4k allocation vs grabbing successively
 > large chucks.
 > 
 > If you have seen similar issues with your fuzz testing let me know where and
 > I'll take a look.

I think /proc/timer_list could probably use the same treatment.
I had traces showing that using 64k allocations too, but I think I may have
just bricked my testbox.

	Dave


  reply	other threads:[~2012-11-06 23:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-06 21:02 [RFC 0/2] /proc/sched_stat and /proc/sched_debug fail at 4096 Nathan Zimmer
2012-11-06 21:02 ` [RFC 1/2] procfs: /proc/sched_stat fails on very very large machines Nathan Zimmer
2012-11-06 21:02   ` [RFC 2/2] procfs: /proc/sched_debug " Nathan Zimmer
2012-11-06 21:31     ` Dave Jones
2012-11-06 23:24       ` Nathan Zimmer
2012-11-06 23:49         ` Dave Jones [this message]
2012-11-07 15:58           ` Nathan Zimmer
2012-11-07  0:37 ` [RFC 0/2] /proc/sched_stat and /proc/sched_debug fail at 4096 Al Viro

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=20121106234949.GA24258@redhat.com \
    --to=davej@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=nzimmer@sgi.com \
    --cc=peterz@infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.