> hm, i'm not convinced about this one. It increases the code size a bit Tiny bit (<200 bytes) and the wait_for/sleep_on refactor patch in the series saves over 1K so I should have some room for code size increase. Overall it will be still considerable smaller.Unfortunately not -- for this to work (especially for inlining) requires to #include files implementing the sub calls. Except for the scheduler that is pretty uncommon unfortunately. Also the situation regarding which call target is the common one is typically much less clear than with sched_fair / other scheduling classes. I considered making it generic, but I don't think it would make sense at the current time. Also most paths are not as time critical as the scheduler. It might have been measurable if the context switch was measurable at all. Unfortunately the lmbench3 lat_ctx test I tired fluctuated by itself over 50%. Ok I suppose it would be possible to instrument the kernel itself to measure cycles. Would that convince you? -Andi -
| Andrew Morton | -mm merge plans for 2.6.23 |
| Greg Kroah-Hartman | [PATCH 004/196] Chinese: add translation of SubmittingPatches |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Gabriel C | Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS] |
git: | |
| Gerrit Renker | [PATCH 03/37] dccp: List management for new feature negotiation |
| David Miller | [GIT]: Networking |
| Thomas Jarosch | Re: TCP connection stalls under 2.6.24.7 |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
