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

[Joshua Judson Rosen]

Benjamin Scott <dragonhawk at gmail.com> writes:
>
> On Sun, Sep 5, 2010 at 10:12 PM, Joshua Judson Rosen
> <rozzin at geekspace.com> wrote:
> > > X reports a resident size of 40 MB, although how much of
> > > that (if any) might actually be video card RAM I dunno.
> >
> > I bet none of it is video-card RAM; a significant (not necessarily
> > majority, but significant) portion of the RAM `used by X', though,
> > is shared libraries that are also used by other processes--and those
> > are basically `gratis' since you'd be using them regardless.
> 
>   I'm approaching the limits of my understanding now, but:
> 
>   I note that several of the shared libraries you list are specific to
> the X server, and thus aren't shared by any other process.

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,
is unnecessary even on my laptop (unless I want accelerated 3-D,
which I *almost* never do--even on my laptop); libfreetype could
presumably be eliminated if we just used bitmap fonts (which is
probably what one wants on a QVGA display, anyway).

And, of course: there are plenty more, in the full listing,
of all types--ones that are specific to the X server, ones that are
specific to other applications (some of them X clients), and ones that
are shared between all sorts of processes. I wasn't trying to prove you
wrong (at all, let a lone by by slight of hand), just pointing out that
there's deeper analysis necessary in order to actually figure out what
the top-level memory-usage figures really mean.

Though...:

>   I've never used memstat before, but the manual page states that it
> reports "virtual memory".  I was looking at the "RSS" (resident
> segment size) column of ps.

Oh, right--you did say "resident", but I managed to miss it....

I think the whole bit about picking through with memstat is
basically irrelevant, in that case, because...:

> 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))

Skimming & grep'ing through Linux 2.6 source that I have on hand,
it looks like mmap() contributes to VSZ but never to RSS, which
I guess makes sense--and it would explain why, even though
I'm *zero bytes* into swap, I still have a huge mismatch
between VSZ and RSS for many of my processes. And that mmap
business applies to shared libraries, if I recall correctly....

The only thing that comes to mind about how RSS might be misleading,
here, is maybe some `unused regions' that *could* be swapped out
(if you had /proc/sys/vm/swappiness cranked up, or had more disk I/O)
but aren't.

I guess, in general, you have to worry about copy-on-write
pages from forks, but that's probably not so relevant here.

The bit I mentioned earlier, about how a bunch of the memory
that appears to be used by the X server process is actually
allocated on behalf of client processes (some applications--
and toolkits--are *much* `worse' about this than others),
may be most relevant, depending on whether you were actually
running any X clients when you did your measurements.


> 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, memstat's basically too dumb
to be of service. But I'd say that the VSZ figures are what're
most in need of a tool like memstat to explain them, so... :)

Though, it *would* be nice to be able to get an idea about
how much of that RSS figure was actually due to loading
and using particular libraries. I don't know how one could
go about doing that.

If you just want to know whether Xorg can run on Ben Nanonote,
it'd probably be most straight-forward (and maybe even more
cost-effective, if your day-job pays hourly ;)) to just...
buy one and try it out. :)

>   (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.

If you go through a full listing fro mmemstat, you'll actually see
things like /dev/dri/card0 and /dev/mem as separate maps (in use
exclusively by the X server, hopefully).

-- 
"Don't be afraid to ask (λf.((λx.xx) (λr.f(rr))))."