Messages in this thread | | | Date | Fri, 25 Sep 1998 21:08:10 +1000 | From | Richard Gooch <> | Subject | Re: Interesting scheduling times - NOT |
| |
Kurt Garloff writes: > > --jRHKVT23PllUwdXP > Content-Type: text/plain; charset=us-ascii > > On Wed, Sep 23, 1998 at 01:55:57AM +0300, Jukka Tapani Santala wrote: > > On Tue, 22 Sep 1998, Kurt Garloff wrote: > > > w/32 procs per proc > > > proc thread proc thread proc thread > > > 2.1.120 6.5 2.8 28.3 22.0 0.68 0.60 > > > 2.1.122 FPU 6.0 3.9 28.1 22.1 0.69 0.57 > > > 2.1.122 both 4.7 2.5 16.4 11.2 0.37 0.27 > > > > I'm surprised... It's my recollection that unaligned data is far slower > > than cache misses. I guess accessing byte-aligned bytes isn't that bad, > > though. Still I'd be very interested to see statistics on different > > computers, and (if the structures aren't specific to one architechture - > > can't check just now. If they are, ignore this;) most importantly > > architechtures. Which is the unfortunate point in optimizations like > > this; they're kinda architechture-dependent. > > As I pointed out in a private mail, the SMP fields (which I changed to > bytes) are not accessed on my UP machine. So the quite good results have > nothing to do with them. > IIRC, accessing byte-aligned bytes on a IA32 is not that bad. Maybe PPro and > P-II don't like it, I don't know, but Pentium, Cx6X86 and K6-2 are OK, AFAIK. > > > But if you're going to optimize for special cases, see the "Optimization > > Manuals" on Intel's website - they give good insight into the cache- and > > burst-loading sequences on Intel architechtures. I would, also, try to > > profile with int's instead of char's to see if it's possible to find an > > even faster combination between cache-line use and misalignment costs. > > But then, I don't have the references in question handy to say if that's > > supposed to have any effect, either ;) > > It might be bad on other archs to use bytes, so I changed it back to ints. > I had to move exec_domain to the third cache line in order to have enough > space for the important variables. > I could have done this in the first place, but I didn't want to touch too > much fields. > > I append a current patch. It's not tested. I don't know if the kernel will > crash (very unlikely, unless I messed the order within INIT_TASK and by > chance the compiler doesn't catch it, because the types are the same) > or what the scheduling performance will be (I'm pretty sure it would be the > same as with my previous patch on UP systems). It compiles at least. > > I will provide results after the weekend, when I'm back. > > Linus, what do you think? Regardless, whether Richard's test is > broken (as Larry claims) or not (as I think), it is certainly a good > idea to have the task_struct ordered to be cache-friendly, isn't > it. I really think that it would be a good idea to have it in the > kernel.
Careful. I did further measurements and some other things slowed down. Check http://www.atnf.csiro.au/~rgooch/benchmarks/ for the details. That may be because I didn't try to optimise other cases: your patch might not have the same problems. It would be worth you trying out the benchmark to see what effects it has.
Regards,
Richard....
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |