X11 on small systems? (was: Qi-Hardware Nanonote group purchase?)

[Benjamin Scott]

On Mon, Sep 13, 2010 at 4:47 PM, Joshua Judson Rosen
<rozzin at geekspace.com> wrote:
> Yes, however: several of the libraries that are exclusive to
> the X server are actually things that would (or could) be eliminated
> in different use-cases; the 4-MB Intel DRI module, for example,

  Good point.  X.org doesn't necessarily have to be as heavy as it is
on a desktop PC.   And has been mentioned, there are more lightweight
X servers out there.

>> Virtual size can include things which aren't main RAM.
>
> I'm going to go a step further, contradicting the prevailing wisdom
> of the Internet, and say that VSZ can even include that aren't even
> properly `allocated *virtual* memory'. What I mean is:
>
>    RSS != (VSZ - (amount of memory paged out to swap))

  Contrary to popular belief and several OS GUIs, "virtual memory"
does not mean "using disk as virtual RAM".  That is, "virtual memory"
is *not* synonymous with "swap space".  Virtual memory is the address
space seen by a process and provided by the MMU.  On i386, the virtual
memory space is always 4 GiB (per process).

  The MMU can map pages of virtual memory to the hardware address
space, or leave them unmapped.  Hardware address space includes both
main RAM and other hardware stuff (like ROMs, often video RAM, some
other kinds of hardware buffers (depending on design), etc.).

  Pages which aren't mapped cause a page fault if the process tries to
read or write that page.  At that point it's up to the kernel memory
manager to decide what to do.   If it's a page written out to swap,
the kernel can read it back in.  If it's a page from a mmap'ed file,
the kernel can do the I/O to put that block in RAM.

  I don't actually know what the "virtual size" figure represents.

  My expectation was that "virtual size" was the total size of all
objects the kernel memory manager had associated with a given
process's virtual memory space (not necessarily mapped).  That would
include all "regular" memory allocated, plus every mmap'ed file (and
thus every shared library).  For X, that might also include video card
RAM.  It might even include things which have no "real" representation
at all:

blackfire$ sudo memstat | grep nvidia0
  42560k: PID  3000 (/dev/nvidia0)
3278332k: /dev/nvidia0 3000
blackfire$

  That's over 3 GiB.   My video card has 256 MiB RAM, main RAM is 1
GiB.  So whatever that is, it isn't hardware.

  However:

blackfire$ ps u 3000
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      3000  0.6  4.6  72248 48448 tty7     SLs+ Aug16 255:59 /usr/bin/X :0
blackfire$

  Note that ps is reporting X as having a virtual size of roughly 72 MiB.

  The ps(1) man page says, of VSZ, that "Device mappings are currently
excluded".  I guess that helps explain the difference, but I'm still
not really sure what VSZ actually represents.

  But in any event, "virtual memory" doesn't have any necessary
correlation to committed primary or secondary storage (i.e., RAM or
disk).

>> It would appear that memstat breaks out memory-mapped files, but how
>> does it treat things like pages swapped to disk?
>
> Oh, it doesn't--at all. If you care about anything other than
> making sense out of VSZ figures ...

  Pages which are not mapped (which includes swapped pages) still
exist in virtual memory.  That's what lets the OS swap them back in as
needed.

>>  (I wouldn't expect RSS to include RAM mapped from the video card,
>> but I didn't know that for sure, hence my qualification earlier.)
>
> I could be mistaken, but my bet is based on the idea that Xorg
> just mmaps /dev/mem (and /dev/dri/card0 and stuff like that, too,
> I guess?) to get at graphics cards' resources.

  That's similar to my understanding as well, but again, I don't know
for sure.  :)

-- Ben