On Fri, May 02, 2008 at 02:59:29PM +0200, Peter Zijlstra wrote:Yeah, I'm just talking about the wait=0 case. (btw. I'd rather the core API takes some data rather than allocates some itself, eg because you might want to have it on the stack). For the wait=1 case, something very clever such as processing pending requests in a polling loop might be cool... however I'd rather not add such complexity until someone needs it (you could stick a comment in there outlining your algorithm). But I'd just rather not have peole rely on it yet. At least with IPIs I think we can guarantee they will be processed on the target after we queue them. It would be handy. The "quickly kick something off on another CPU" is pretty nice in mm/ when you have per-cpu queues or caches that might want to be flushed. --
| Srivatsa Vaddagiri | containers (was Re: -mm merge plans for 2.6.23) |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Benjamin Herrenschmidt | Re: [PATCH] Remove process freezer from suspend to RAM pathway |
git: | |
| Jarek Poplawski | [PATCH take 2] pkt_sched: Protect gen estimators under est_lock. |
| David Miller | [GIT]: Networking |
| Gerhard Pircher | 3c59x: shared interrupt problem |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
