Messages in this thread | | | Date | Tue, 20 May 2014 22:08:30 +0200 | From | Frederic Weisbecker <> | Subject | Re: [PATCH 5/5] workqueue: Allow modifying low level unbound workqueue cpumask |
| |
On Tue, May 20, 2014 at 03:56:56PM -0400, Tejun Heo wrote: > > > Hmmm... but there's nothing which makes rolling back more likely to > > > succeed compared to the original applications. It's gonna allocate > > > more pwqs. Triggering WARN_ON_ONCE() seems weird. > > > > Yeah but that's the least we can do. If we fail to even recover the old cpumask, > > the user should know about the half state fail. > > I'm failing to see how it'd be better than just going through applying > the new mask if we're likely to end up with half-updated states > anyway. What's the point of another layer of best effort logic which > is more likely to fail?
If the error is -ENOMEM then yeah, but any other error wants rollback.
> > But it's going to imply fun with double linked list of struct pwq_allocation_object > > and stuff. Or maybe an array. This reminds be a bit generate_sched_domains(). It's > > not going to be _that_ simple nor pretty :) > > Is it tho? Don't we just need to keep a separate staging copy of > prepared pwq_tbl? The commit stage can be pwq_tbl installation. > Looks like it shouldn't be too much of problem. Am I missing > something?
Sure, that still need an iteration array/list of pre-allocated objects. Expect at least one more hundred lines.
> > > > 2. Proper error handling is hard. Just do pr_warn() on each failure > > > and continue to try to apply and always return 0. > > > > > > If #1 isn't too complicated (would it be?), it'd be the better option; > > > otherwise, well, #2 should work most of the time, eh? > > > > Yeah I think #2 should be way enough 99% of the time :) > > Yeah, if #1 gets too hairy, #2 can be a reluctant option but if #1 is > doable without too much complication, I'd much prefer proper error > handling.
I can try yeah.
| |