> A segment descriptor cache could speed up such segment load> operations. I don't know which, if any, processors had one.> I have been told that some did, but have never seen it in any> Intel or AMD literature.

As I understand it, they all have such a cache, except for certain
early steppings of the original Pentium. When it was discovered that
the omission of the cache had a disasterous effects on the execution
speed of some legacy (mostly 16-bit) software, Intel were quick to put
the cache back into their later models.

The Intel models have a cache of 96 extended descriptors, and the
AMD models have 128 I think.

To be honest, I'm not quite sure how the discussion got onto
segmentation in this thread, but never mind :-)

>> All in all I agree with your guess about page table manipulation>> for fast block moves. Why move memory around byte by byte, when>> moving bigger entitites (pages) costs about the same time, per>> entity?>> As I understand it, it is common on many systems for the memory> allocation system to fill page tables with pointers to one zero> filled page, and then allocate a real page with the first write> operation.

I don't understand why it is necessary for the PTEs to be set to
point to any frame. Why not just set the P bit to 0?

> There is a story of someone testing the cache memory> characteristics of a machine with C code like:>> int *a,*b,i;> a=malloc(100000000);> b=malloc(100000000);> for(i=0;i<100000000;i++) a[i]=b[i];>> It would seem that this would require moving enough data to> completely flush the cache, but it might not.

An interesting test, but not really a fair test of a machine's
speed, since it is somewhat unrepresentative of real workloads.