[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200904142212.35264.rusty@rustcorp.com.au>
Date: Tue, 14 Apr 2009 22:12:34 +0930
From: Rusty Russell <rusty@...tcorp.com.au>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Valdis.Kletnieks@...edu, Mike Travis <travis@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
mm-commits@...r.kernel.org, Dave Jones <davej@...hat.com>,
Ingo Molnar <mingo@...e.hu>
Subject: Re: mmotm 2009-04-10-02-21 uploaded - forkbombed by work_for_cpu
On Tue, 14 Apr 2009 01:34:23 am Linus Torvalds wrote:
> So the _real_ problem came through the commits like
>
> cpufreq: use work_on_cpu in acpi-cpufreq.c for drv_read and drv_write
> cpumask: use work_on_cpu in acpi-cpufreq.c for read_measured_perf_ctrs
>
> that were meant to reduce stack usage with big cpu masks. And sure, the
> _old_ way of doing it was also stupid (it rescheduled the process to the
> other CPU by using cpus_allowed()).
Reducing stack was main motivation, but old way was actually wrong: not only
can userspace see the affinity change, it can mess it up by setting it at the
same time.
It used to be reasonably quick, but forking a thread (to prevent locking
problems with keventd and yet avoid YA 1-thread-per-cpu) made it worse.
I'm no expert, but would life be more pleasant if the core cpufreq code
called these methods bound to an appropriate CPU? They all seem to do these
tricks...
Cheers,
Rusty.
--
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/
Powered by blists - more mailing lists