Re: [PATCH 2.6.16-mm1 1/2] sched_domain: handle kmalloc failure

[Paul Jackson <pj@sgi.com>]

Vatsa wrote:
> I think even if memory allocation fails while making a cpuset exclusive,
> we would still want have the cpuset marked exclusive.

Perhaps ...

The cpuset code itself in the kernel doesn't care at all whether the
dynamic sched domain setup succeeds or not.

If the user or app that made the system call (write '1' to
cpu_exclusive) was setting cpu_exclusive to get a sched domain,
they would want to know if it failed.  If they were looking for one
of the other consequences of an exclusive cpuset, then such an error
is possibly confusing noise.

I keep wishing I had made a separate per-cpuset flag to mark a
cpuset as defining a dynamic sched domain.  Had I done that, I would
definitely want to pass back an error in this case.

But even if the user/app isn't interested in this failure case,
probably the 'good kernel citizen' choice is to report it.  The kernel
should report errors to fail to accomplish requested tasks, and not
second guess whether the user actually cares about that error.

And if we do report an error back to userland, then the request to
set cpuset_exclusive needs to fail entirely, not setting it at all.

So ... bottom line ... when and if it becomes convenient to do so,
have the kernel/sched.c:partition_sched_domains() routine return
an error instead of void.  Then sometime later on, I can change the
cpuset code to pick up that error, unravel the cpu_exclusive setting,
and pass back the error.

But take your sweet time doing this -- no hurry here.

And if you decide it isn't worth the code or effort to do this,
I will gladly forget the whole thing.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/