Messages in this thread | | | Date | Fri, 27 May 2005 01:44:30 -0700 | From | Paul Jackson <> | Subject | Re: [PATCH 2.6.12-rc4] cpuset exit NULL dereference fix |
| |
Simon wrote: > > Would it make sense, Simon, to recommend to Andrew that > > he take the simple patch I submitted yesterday ... > > > > Then, when we understand ... offer up a second patch? > > Of course !
Ok - I'll resubmit that patch. Hopefully you can reply to that resubmitted patch with an "Acked-by: ..."
Andrew withdrew the original patch, when it became a matter needing further discussion.
> My point is only that if you think there is a scaling problem in > taking cpuset_sem for each call to cpuset_exit(), that scaling problem > won't disappear by taking cpuset_sem only for 'notify_on_remove' cpusets,
Yes - that is a good and valid point.
I also lack any real evidence of a scaling problem. It's just a theoretical concern. My unreliable weather forecast is that it will be a while before it's a serious concern.
This means I am willing to take simple measures to minimize the concern, but I'd prefer to await hard evidence of the problem before trying more ambitious measures.
==
My impression is that cpusets has two classes of users: 1) Extreme HPC apps, scaling to hundreds or thousands of CPUs, and 2) More mixed or service oriented apps, with less extreme scaling.
I also suspect that it is the second class that most requires notify_on_release. The extreme HPC guys have less need for notify_on_release.
So I find a solution that lets one trade off extreme scaling versus heavier use of notify_on_release to be appealing, if it can be done trivially, as this patch does.
-- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 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/
| |