[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080805232856.78dd50f7.pj@sgi.com>
Date: Tue, 5 Aug 2008 23:28:56 -0500
From: Paul Jackson <pj@....com>
To: Max Krasnyansky <maxk@...lcomm.com>
Cc: mingo@...e.hu, linux-kernel@...r.kernel.org, menage@...gle.com,
a.p.zijlstra@...llo.nl, vegard.nossum@...il.com,
lizf@...fujitsu.com
Subject: Re: [PATCH] cpuset: Rework sched domains and CPU hotplug handling
(2.6.27-rc1)
Max wrote:
> ... the wrong part of my reply ...
Was the right part where you wrote:
> We'd actually be changing more things.
I also don't care that much how much code is changed;
if it must be changed, then change it to what is best,
which may not necessarily be the minimum change.
If an asynchronous sched domain rebuild is needed in
some places, then consider just using it everywhere,
rather than providing two code paths to rebuild, one
sync and one async.
Ask not how we got here; ask where we should be.
In particular, and in this specific case, having the
dual code paths really did make it a little more difficult
for me to understand the code, as evidenced by the back
and forth discussion on how to name the confusingly
similar functions. Such naming controversies are usually
a sign of code duplication or improper factoring.
That additional difficulty in understanding this code
was a key factor in delaying my review of your code.
I'd look at it, my mind was glaze over, and I'd put
it aside for a few days. This happened repeatedly.
Fine code is like fine art ... spare, elegant, compelling
in its expression.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@....com> 1.940.382.4214
--
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