Ingo Molnar wrote:Sure, so long as you take "as cheap as possible" to mean cheap in both implementation complexity as well as runtime cost. I don't have any specific objections to any of the stuff that Mathieu is working on, but it does worry me that each time a problem is addressed it ends up being an even more subtle piece of code. I just haven't seen enough concrete justification to make me feel comfortable with it all. It seems to me that a relatively simple implementation which allows the desired tracing/marking functionality is the first step. If that proves to cause a significant performance deficit then enabled then we can work out how to address it in due course. But doing it all at once before merging anything seems like overkill, particularly when we're talking about specifics of gcc's codegen patterns, disassembling code fragments, etc. J --
| David Miller | Re: Slow DOWN, please!!! |
| debian developer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Roland Dreier | Re: Integration of SCST in the mainstream Linux kernel |
| Ingo Molnar | Re: containers (was Re: -mm merge plans for 2.6.23) |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Josip Rodin | bnx2_poll panicking kernel |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 13/37] dccp: Deprecate Ack Ratio sysctl |
