From: Zhuang, L. <lou...@in...> - 2002-09-13 04:20:42
|
Dear all, Because LSE modify many critical components in Linux, should these patches be surrounded by some kernel config option such as CONFIG_LSE? I expect that LSE can be enabled/disabled quickly so as to measure performance enhancements quickly. Louis Zhuang, SW Engineer, Intel Corporation. My opinions are my own and NEVER the opinions of Intel Corporation. I am but a tiny, insignificant, infinitesimal (1/60000) cog in the giant machine of Intel ^_^ |
From: Martin J. B. <mb...@ar...> - 2002-09-13 04:31:37
|
> Because LSE modify many critical components in Linux, should > these patches be surrounded by some kernel config option such as > CONFIG_LSE? I expect that LSE can be enabled/disabled quickly so > as to measure performance enhancements quickly. Why not just keep a patched and unpatched source tree? How hard is that, really? It's much nicer if the patches can be submitted as tested, rather than having to be altered again, and it'll make a horrible mess of the code (with the lse patch). M. |
From: Dipankar S. <dip...@in...> - 2002-09-13 05:22:35
|
On Fri, Sep 13, 2002 at 10:52:56AM +0800, Zhuang, Louis wrote: > Dear all, > Because LSE modify many critical components in Linux, should these patches > be surrounded by some kernel config option such as CONFIG_LSE? I expect that > LSE can be enabled/disabled quickly so as to measure performance > enhancements quickly. > I don't think that is a good idea, not to mention that the mess if you wrap #ifdef CONFIG_LSE around all that code spread all over the place. I would much rather see a well thought out merge order for for conflicting patches and then a series of sequenced patches in that order. Thanks -- Dipankar Sarma <dip...@in...> http://lse.sourceforge.net Linux Technology Center, IBM Software Lab, Bangalore, India. |
From: Martin J. B. <mb...@ar...> - 2002-09-13 05:28:52
|
> I would much rather see a well thought out merge order for > for conflicting patches and then a series of sequenced patches > in that order. Right. Andrea has a nice system for doing this 00-patchA 01-patchB 01-patchC 02-patchD apply all 00s, then all 01s (in any order) then all 02s, etc. Of course this means you can do "for i in patches/*; do; patch -p1 < $i; done". And it's simple to see what happens, merge things forward, and split them out again when the time comes. I've been following his method for a while ... works great. M. |