[lkml]   [2005]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] cpuset semaphore depth check optimize

On Mon, 12 Sep 2005, Andrew Morton wrote:
> Better, but still hacky. The rest of the kernel manages to avoid the need
> for nestable semaphores by getting the locking design sorted out. Can
> cpusets do that sometime?

Well, if you "rest of the kernel" you ignore the BKL, then yes.

Nesting isn't wrong per se - sometimes it allows things that would
otherwise be very nasty to code around. We've been very strict with not
allowing nesting for the low-level primitives (ie spinlocks etc), and
instead requiring that people use them very carefully, but I don't think
nesting is necessarily wrong for high-level constructs.

Personally, the thing that makes me think the patch is ugly is the fact
that the different parts of the nested semaphore are all separate. I'd
prefer to see a

struct nested_semaphore {
struct semaphore sem;
struct task_struct *owner;
unsigned int count;

and then operate on _that_ level instead.

But keep it internal to the cpuset stuff - while I don't think nested
semaphores are evil, they _are_ sometimes an excuse to be lazy and do
things wrong just because it's easier.

Maybe that's the case in cpusets too, and Andrew may be right about this.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2009-11-18 23:46    [W:0.109 / U:0.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site