Re: [PATCH] 2.6.9 Use skb_padto() in drivers/net/8390.c
On Sad, 2005-02-19 at 05:20, Jeff Garzik wrote: > > It means that padto has improved a lot (or the underlying allocators). > > It also still means the patch makes the code slower and introduces > > changes that have no benefit into the kernel, so while its good to see > > its not relevant its still a pointless change. > > So the verdict is to revert? Not sure. The old code is known to work and a fraction faster, the new code makes the driver use the same logic as the others. Having seen the numbers from Paul I personally don't care either way. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.6.9 Use skb_padto() in drivers/net/8390.c
On Sad, 2005-02-19 at 05:20, Jeff Garzik wrote: It means that padto has improved a lot (or the underlying allocators). It also still means the patch makes the code slower and introduces changes that have no benefit into the kernel, so while its good to see its not relevant its still a pointless change. So the verdict is to revert? Not sure. The old code is known to work and a fraction faster, the new code makes the driver use the same logic as the others. Having seen the numbers from Paul I personally don't care either way. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.6.9 Use skb_padto() in drivers/net/8390.c
Alan Cox wrote: On Llu, 2005-01-10 at 02:41, Paul Gortmaker wrote: Using rdtscl over the area affected by the patch on the two variants for a sample of 234 small packets, I see an average of 4141 for using the existing stack scratch area, and 4162 for using skb_padto. That is a difference of about 0.5%, which is significantly less than the typical spread in the samples themselves. To help give a relevant scale, feeding it a larger 1400 byte packet comes in at around 60,000 cycles on this particular box. Am I being optimistic to see this as good news -- meaning that there is no longer a need for driver specific padto implementations, whereas it looks like there was back when you did your tests? It means that padto has improved a lot (or the underlying allocators). It also still means the patch makes the code slower and introduces changes that have no benefit into the kernel, so while its good to see its not relevant its still a pointless change. So the verdict is to revert? Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.6.9 Use skb_padto() in drivers/net/8390.c
Alan Cox wrote: On Llu, 2005-01-10 at 02:41, Paul Gortmaker wrote: Using rdtscl over the area affected by the patch on the two variants for a sample of 234 small packets, I see an average of 4141 for using the existing stack scratch area, and 4162 for using skb_padto. That is a difference of about 0.5%, which is significantly less than the typical spread in the samples themselves. To help give a relevant scale, feeding it a larger 1400 byte packet comes in at around 60,000 cycles on this particular box. Am I being optimistic to see this as good news -- meaning that there is no longer a need for driver specific padto implementations, whereas it looks like there was back when you did your tests? It means that padto has improved a lot (or the underlying allocators). It also still means the patch makes the code slower and introduces changes that have no benefit into the kernel, so while its good to see its not relevant its still a pointless change. So the verdict is to revert? Jeff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
