Ingo Molnar wrote on Wednesday, June 22, 2005 12:15 AM
> probably coloring effects, yes. Another reason could be that
> touch_cache() touches 6 separate areas of memory, which combined with
> the stack give a minimum of 7 hugepage TLBs. How many are there in these
> Xeons? If there are say 4 of them then we could be trashing these TLB
> entries. There are much more 4K TLBs. To reduce the number of TLBs
> utilized, could you change touch_cache() to do something like:
>
> unsigned long size = __size/sizeof(long), chunk1 = size/2;
> unsigned long *cache = __cache;
> int i;
>
> for (i = 0; i < size/4; i += 8) {
> switch (i % 4) {
> case 0: cache[i]++;
> case 1: cache[size-1-i]++;
> case 2: cache[chunk1-i]++;
> case 3: cache[chunk1+i]++;
> }
> }
>
> does this change the migration-cost values?
Yes it does. On one processor, it goes down, but goes up on another.
So I'm not sure if I completely understand the behavior.
vmalloc'ed __get_free_pages
3.0GHz Xeon, 8MB 6.46ms 7.05ms
3.4GHz Xeon, 2MB 0.93ms 1.22ms
1.6GHz ia64, 9MB 9.72ms 10.06ms
What I'm really after though is to have the parameter close to an
experimentally determined optimal value. So either algorithm with
__get_free_pages appears to be closer.
> Btw., how did you determine the value of the 'ideal' migration cost?
> Was this based on the database benchmark measurements?
Yes, it is based on my favorite "industry standard transaction processing
database" bench (I probably should use a shorter name like OLTP).
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
