RFD: setting up a minimal xorg configuration

[Tiago Vignatti]

On Wed, Apr 14, 2010 at 10:58:58PM +0200, ext Adam Jackson wrote:
> On Wed, 2010-04-14 at 21:57 +0300, Tiago Vignatti wrote:
> 
> > For me seems so obvious to conditionalize code that I don't use. I understand
> > that we'll be introducing complexity here, but it's must. IMHO the only thing
> > to discuss is _how_ we should do it, trying to minimize such complexity.
> 
> The problem I have with your attack on this problem - and, don't get me
> wrong, it's an important problem to consider - is that it doesn't seem
> you know what you're measuring.  I mean, --disable-xaa?  You know that
> doesn't get _loaded_ if the driver doesn't request it, right?  And that
> there's zero code in the core server conditional on it?  So not building
> it saves you exactly zero memory at runtime.
> 
> Whereas, to pick an example I happened to spot recently, the loader is
> compiling a small pile of regexes, but then only sometimes using them,
> and anyway we're not doing anything nearly complex enough to justify
> them, let alone leaving them around after painting the root window.  A
> very quick (and possibly incorrect) read of the glibc regex source tells
> me this is going to use >300 bytes per pattern.
> 
> And, like I've said several times now, text is free.  Code you don't
> execute never makes it into physical memory.  Unless you're running out
> of address space in the X server, code size is meaningless.  Dirty data
> size is your _entire_ problem.  That's real memory pressure.  Everything
> else is second-order.
> 
> You really need to look at heap usage.  Even on a desktop OS with
> everything in the world configured and compiled, heap usage completely
> outstrips trivial crap like DSO .data sections at runtime:
> 
> atropine:~% sudo grep -A1 rw-p.*fd /proc/`pidof Xorg`/smaps | awk 'BEGIN { i = 0 } /^Size/ { i += $2 } END { print i }'
> 460
> atropine:~% sudo grep -A1 heap /proc/`pidof Xorg`/smaps
> 092e9000-0ac65000 rw-p 00000000 00:00 0          [heap]
> Size:              26096 kB
> 
> Fight the real enemy.

I agree with all aspects you mentioned here. And definitely it's in my
backlog to analyze heap usage in Xorg.

But the modularization and conditionalization of code in Xorg is not
only about memory saving; I'd say memory saving is the part that I really
don't care here.

*Code organization is the key*

Why Kristian started Wayland? Cause Xorg is a huge pile of ancient code tied
with a immutable protocol. We hear this all the time from people. If we had
minimal server, as I'm targeting, I doubt Kristian would start his project.

The ideal X server implementation is not so tough to imagine: a minimal core
where you can load several modules, drivers, extensions - this all being
static or dynamic doesn't matter. X would literally fit in any kind of device.
Embedded, distro and all the rest of the world would live nicely and very
happy with this implementation.

If I want to analyse the code to suppress the cursor, for instance, I have to
understand some old odd extensions, RAMDAC code from 80's and possibly all the
pointer logic happening in dix. In the worst case the protocol will not let me
to do so. It's damn hard. The code is huge. The code is messy. Everyone is
aware about it. On the other hand, modularization of Xorg, having a minimal
Xorg, means clean code, easy to expand and play with.

IMHO, Keith, as the RM and the one that ultimately says which code goes
upstream, should be very clear about this sort of issue. I can't discuss
future development of X without understand his thoughts. (Sometimes I feel
that our development process is living in Baazar model without someone
dictating it, which doesn't make sense. No offences please, Keith!).

                            Tiago