Messages in this thread |  | | Date | Mon, 11 Sep 2006 10:01:15 +0200 | | From | Ingo Molnar <> | | Subject | Re: 2.6.18-rc6-mm1: GPF loop on early boot |
| |
* Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> Ingo Molnar wrote: > >yes - but loading a null selector is a special-case: you dont have to > >invalidate/reload the shadow, you just have to turn access off. This > >might or might not make a difference on modern CPUs (it makes a > >difference with older CPUs) - but it's worth a try nevertheless. You > >measured a 9 cycles degradation with the %gs method, we could recover > >some of that. > > > > It's a worthwhile experiment. The gain would be the NULL selector > load, but the loss would be an additional segment reload on context > switch and TLS ABI incompatibility (which is more difficult to > quantify).
the ratio between the number of syscalls vs. the number of context switches is 1-2 orders of magnitude. So a loss of 9 cycles in the syscall path is roughly equal to a loss of 90-900 cycles in switch_to() costs ...
the TLS ABI is just a gcc stupidity. Why did they pick the _second_ extra selector, instead of the first one ...? Anyway, perhaps this could be solved by extending gcc with a switch to also generate __thread code off %fs. Probably not worth the pain though ...
Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |