Messages in this thread | | | Date | Tue, 24 Feb 2015 11:37:23 +0100 | From | Ingo Molnar <> | Subject | Re: live patching design (was: Re: [PATCH 1/3] sched: add sched_task_call()) |
| |
* Jiri Kosina <jkosina@suse.cz> wrote:
> On Sat, 21 Feb 2015, Ingo Molnar wrote: > > > (It does have some other requirements, such as making > > all syscalls interruptible to a 'special' signalling > > method that only live patching triggers - even syscalls > > that are under the normal ABI uninterruptible, such as > > sys_sync().) > > BTW I didn't really understand this -- could you please > elaborate what exactly do you propose to do here in your > "simplified" patching method (i.e. serializing everybody > at the kernel boundary) for TASK_UNINTERRUPTIBLE > processess?
So I'd try to separate out the two main categories of uninterruptible sleepers:
- those who just serialize with other local CPUs/tasks relatively quickly
- those who are waiting for some potentially very long and open ended request. [such as IO, potentially network IO.]
I'd only touch the latter: a prominent example would be sys_sync(). I'd leave alone the myriads of other uninterruptible sleepers.
> But I didn't understand your claims regarding > uninterruptible sleeps in your paragraph above. > sys_sync() is one thing, that's just waiting > uninterruptibly for completion. But how about all the > mutex waitiers in TASK_UNINTERRUPTIBLE, for example?
I'd not touch those - unless they are waiting for something that will not be done by the time we park all tasks: for example NFS might have uninterruptible sleeps, and sys_sync() will potentially do IO for minutes.
I think it would be the exception, not the rule - but it would give us an approach that allows us to touch 'any' kernel code if its wait times are unreasonably long or open ended.
Thanks,
Ingo
| |