linux-kernel - Re: [PATCH RESEND 2/4] sched: /proc/sched_debug fails on very very large machines.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20130116135647.019cbe8d.akpm@linux-foundation.org>
Date:	Wed, 16 Jan 2013 13:56:47 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Nathan Zimmer <nzimmer@....com>
Cc:	mingo@...hat.com, peterz@...radead.org, tglx@...utronix.de,
	johnstul@...ibm.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RESEND 2/4] sched: /proc/sched_debug fails on very very
 large machines.

On Tue, 15 Jan 2013 15:46:10 -0600
Nathan Zimmer <nzimmer@....com> 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.
> 
> The output should be identical to previous version.
> 
> ...
>
> +	int cpu = (unsigned long)(v - 2);

Again, the meaning of the magic offsets are unobvious to readers of
this code.

> -	SEQ_printf(m, "\n");
> +	if (cpu != -1)
> +		print_cpu(m, cpu);

Same concerns with cpu hotplug.

> +	else
> +		sched_debug_header(m);
>  
>  	return 0;
>  }

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/