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

[BlaisorBlade <blaisorblade_spam@yahoo.it>]

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