Chuck and ddb have saved the day again.

Jason and others were correct, it DOES involve something to do with screwy color
models and fragmented allocations in the server.

I was correct, there IS something fishy in the way it's being handled vm-wise.

Consider an image which, at 350x234 in 16-bit color, occupies 160K.  When the X
server allocates this, it winds up with two map entries backed by two separate
objects.

The address range for each map entry only covers 1 page, but the object backing
each entry has 40 pages, all of which are resident.

Looking at the objects reveals that, indeed, all 80 pages (320K) are there, and
the pages of the two objects seem to be interleaved, or alternating.

What's more, these objects DO NOT go away when the client that sent the data to
the server exits.  I'm not sure if that's because the malloc thinks it's only
caching 8K (two pages), or because the server just hangs onto them.  Either
way, it explains why only 8K turns up in the server's RSS:  that's all its map
entries show.  The active list, naturally, shows all 320K.

Which is why I STILL say the old Mach vm seems to have a problem here.  I can't
see how you get 1-page map entries for 40-page objects.  If the server
requested two 40-page allocations, the map entries should reflect that.  If the
server somehow requested the second allocation overlapping all but the first
page of the first allocation, what should have happened to the 39 overlapped
pages in the first vm object?!?

Incidentally, the next server map entry appears to be a copy of the screen,
which is continually deallocated and reallocated to keep it on top of the
(hypothetical) heap.  It overlaps all but the first page of the second
allocation described above.  (The presence of this seems rather inefficient,
since backing-store and save-under are turned off, and the background is just a
solid color.)

Anyway, the problem is well on its way to being thoroughly explained now. 
Thanks to everyone who commented.

Now, I have an appointment to get a hammer surgically removed from my thumb....


--Jim Howard  <jiho@mail.c-zone.net>


----------------------------------
E-Mail: jiho@mail.c-zone.net
Date: 27-Apr-98
Time: 15:02:58

This message was sent by XFMail
----------------------------------