[uml-devel] Re: [UML] Performance hit for setting CS segment limit

[uml-devel] Re: [UML] Performance hit for setting CS segment limit

[Ingo Molnar]

* BlaisorBlade <blaisorblade_spam@yahoo.it> wrote:

> Hi Ingo, I need some help from you about the performance hit of
> segmentation, which you probably studied for the exec-shield patch.
> 
> In short: if I reduce the limit of the CS, DS and so on segment
> descriptors (let's say it becomes 2,5G instead of 4G), a bit like you
> do in the exec-shield patch, will this setting impact on the
> performance of the process, apart for the time to set them? I also
> assume that segment changes do not flush the TLBs; is this correct?
> 
> I've been told by Jeff Dike (you can check on the ML) that :
> 
> "This is slow, plus ****using segments will cost you a cycle or
> something on EVERY memory reference***. Alan Cox warned me off very
> strongly against doing this.", though maybe he referred to something
> different: is this true in this case?

this might be true for _data_ segments, but not for the code segment.
The code segment limit can be checked when an iTLB miss occurs, no need
to check during code prefetch itself. So there's no overhead.

	Ingo


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: [UML] Performance hit for setting CS segment limit

[BlaisorBlade]

Alle 07:45, martedì 15 giugno 2004, Ingo Molnar ha scritto:
> * BlaisorBlade <blaisorblade_spam@yahoo.it> wrote:
> > Hi Ingo, I need some help from you about the performance hit of
> > segmentation, which you probably studied for the exec-shield patch.
> >
> > In short: if I reduce the limit of the CS, DS and so on segment
> > descriptors (let's say it becomes 2,5G instead of 4G), a bit like you
> > do in the exec-shield patch, will this setting impact on the
> > performance of the process, apart for the time to set them? I also
> > assume that segment changes do not flush the TLBs; is this correct?
> >
> > I've been told by Jeff Dike (you can check on the ML) that :
> >
> > "This is slow, plus ****using segments will cost you a cycle or
> > something on EVERY memory reference***. Alan Cox warned me off very
> > strongly against doing this.", though maybe he referred to something
> > different: is this true in this case?
>
> this might be true for _data_ segments

Well, sadly I need to know for those also... however I'm going to search 
myself.

>, but not for the code segment.
> The code segment limit can be checked when an iTLB miss occurs

And so iTLB means instruction TLB, right? (I was wondering about this in your 
discussion about 4G/4G patch with Andrea Arcangeli).

Also, from some tests, I would guess that also for Celeron, and not only for 
Xeon, there are at least 64 dTLB. Is this correct? I used this to explain 
some benchmark datas.

I noticed that when touching more than 64 different pages (i.e. 512 in my 
test), flushing or not the TLBs gave almost no "secondary cost" for reloading 
them when re-touching those pages, while the secondary cost was very high 
with 64 pages.

>, no need
> to check during code prefetch itself. So there's no overhead.

The only difference, here, is that for data segments, which are also important 
here, on a dTLB (i.e. I guess dTLB = data TLB) fault the check is done for a 
certain segment, so it could have a little overhead (though Intel claims it 
is done in parallel with address translation, in their manuals).

Thanks a lot!
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729



-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: [UML] Performance hit for setting CS segment limit

[Ingo Molnar]

* BlaisorBlade <blaisorblade_spam@yahoo.it> wrote:

> >, but not for the code segment.
> > The code segment limit can be checked when an iTLB miss occurs
> 
> And so iTLB means instruction TLB, right? (I was wondering about this
> in your discussion about 4G/4G patch with Andrea Arcangeli).

yeah.

> Also, from some tests, I would guess that also for Celeron, and not
> only for Xeon, there are at least 64 dTLB. Is this correct? I used
> this to explain some benchmark datas.

'x86info -c' will tell you precisely how many TLBs there are for each 
type.

> I noticed that when touching more than 64 different pages (i.e. 512 in
> my test), flushing or not the TLBs gave almost no "secondary cost" for
> reloading them when re-touching those pages, while the secondary cost
> was very high with 64 pages.

yes, there are such boundaries. (they are often not precisely at 64
pages because code also needs a stack and maybe global variables, but
generally it's around the # of dTLBs.)

> >, no need
> > to check during code prefetch itself. So there's no overhead.
> 
> The only difference, here, is that for data segments, which are also
> important here, on a dTLB (i.e. I guess dTLB = data TLB) fault the
> check is done for a certain segment, so it could have a little
> overhead (though Intel claims it is done in parallel with address
> translation, in their manuals).

it depends on the CPU. But generally the more modern an x86 CPU is, the
higher the relative penalty for any segmentation trick ... and this
trend wont stop in the future i'm afraid.

	Ingo


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel