Messages in this thread | | | Date | Tue, 5 Aug 2008 18:05:21 -0500 | From | Paul Jackson <> | Subject | Re: [PATCH] cpuset: Rework sched domains and CPU hotplug handling (2.6.27-rc1) |
| |
Max wrote: > It could I guess. But the questions is why ? > I mean the only reason we've introduced workqueue is because lock > nesting got too complicated. Otherwise in all those paths we're already > in a process context and there is no need to schedule a workqueue.
My priorities are different than yours.
You look at a code path that, in some cases, is more involved than necessary, and recommend providing an alternative code path, for the cases that can get by executing (significantly) fewer CPU cycles.
I look at the number of code paths, lines of code, duplicated code and number of tests and conditions in the source code, and ask how to reduce them. I want the least amount of source code, the fewest alternative paths through that code, the smallest number of logical tests and code variants, the least amount of code duplication.
The key in this case is that I prefer having just one code path by which all rebuilds of sched domains are done. Since that rebuild must be asynchronous for some cases (to avoid ABBA lock nesting problems) therefore let all sched domains be done by that async path.
The fewer the number of code path variants, the easier it is to understand the code, and the harder it is to break the code.
Except for frequently executed code paths, which this surely is not, minimizing software maintenance costs is far more important to me than minimizing CPU cycles.
-- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.940.382.4214
| |