lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 9 Mar 2014 16:28:16 -0700 (PDT) From: David Lang <david@...g.hm> To: Ben Hutchings <ben@...adent.org.uk> cc: David Miller <davem@...emloft.net>, mkl@...gutronix.de, linux-rt-users@...r.kernel.org, linux-kernel@...r.kernel.org, netdev@...r.kernel.org, kernel@...gutronix.de Subject: Re: [PATCH] net: sched: dev_deactivate_many(): use msleep(1) instead of yield() to wait for outstanding qdisc_run calls On Sun, 9 Mar 2014, Ben Hutchings wrote: > On Sun, 2014-03-09 at 18:53 -0400, David Miller wrote: >> From: Ben Hutchings <ben@...adent.org.uk> >> Date: Sun, 09 Mar 2014 19:09:20 +0000 >> >>> On Thu, 2014-03-06 at 16:06 -0500, David Miller wrote: >>>> From: Marc Kleine-Budde <mkl@...gutronix.de> >>>> Date: Wed, 5 Mar 2014 00:49:47 +0100 >>>> >>>>> @@ -839,7 +839,7 @@ void dev_deactivate_many(struct list_head *head) >>>>> /* Wait for outstanding qdisc_run calls. */ >>>>> list_for_each_entry(dev, head, unreg_list) >>>>> while (some_qdisc_is_busy(dev)) >>>>> - yield(); >>>>> + msleep(1) >>>>> } >>>> >>>> I don't understand this. >>>> >>>> yield() should really _mean_ yield. >>>> >>>> The intent of a yield() call, like this one here, is unambiguously >>>> that the current thread cannot do anything until some other thread >>>> gets onto the cpu and makes forward progress. >>>> >>>> Therefore it should allow lower priority threads to run, not just >>>> equal or higher priority ones. >>> >>> Until when? >>> >>> yield() is not a sensible operation in a preemptive multitasking system, >>> regardless of RT. >> >> To me it means "I've got nothing to do if other tasks want to run right >> now" Yes, I even see it having this meaning when an RT task executes >> it. >> >> How else can you interpret the intent above? > > The problem is that 'I've got nothing to do ... now' is information > about a *point* in time, which gives the scheduler no clue as to when > this task might be ready again. So far as task *state* goes, it never > ceases to be ready. > >> If you change it to msleep(1), you're assigning an extra completely >> arbitrary time limit to the yield. The code doesn't want to sleep >> for 1ms, that's not what it's asking for. > [...] > > I think you want to give up a 'time slice' to any task that's available. > But that's not a meaningful concept for all schedulers. If your task is > highest priority and is ready, it must run. You could drop priority > temporarily, but then you need it to somehow be bumped up again at some > time in the future. Well, sleeping effectively does that. > > I do understand that unconditionally sleeping also isn't ideal - the > task that unblocks this one might already be running on another CPU and > able to finish sooner than the sleep timeout. > > Maybe the answer is a yield_for(time) which sleeps for the given time or > until there's an idle CPU, whichever is sooner. But I don't know how > hard that would be to implement or how widely useful it would be. what is msleep(0) defined to do? would it be any better? David Lang -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists