Re: [PATCH] cpuset: Rework sched domains and CPU hotplug handling(2.6.27-rc1)

[Paul Jackson]

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@xxxxxxx> 1.940.382.4214
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/