Re: [forum] A strawman proposal for &

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

> Sender: forum-admin@XFree86.Org
> From: Jim Howard <>
> Date: Tue, 01 Apr 2003 06:02:55 +0000
> To: forum@XFree86.Org
> Subject: Re: [forum] bloatware
> -----
> > Remember folks, please, that we developed X11 on Vax 11/750's with 2 meg
> > of RAM.
> Which only proves you know!  ;)

Yup.  And I've been working on the server and library side of the
problem as much as I've had time to do so.  Unfortunately, while
this is a worthwhile effort, in fact most of the problems we see
are on the client toolkit and applications side.  Most of the
handheld issues have turned out to be culling out which libraries
are actually useful, and getting rid of obsolete cruft.

> By "from the beginning", I guess I meant when X became public and
> workstation vendors got involved; i.e., the beginning of the X we have
> to deal with now.

No, actually, X11 was developed *after* the workstation vendors were
involved, FWIW.  A number of vendors (Digital, HP, for example) shipped
X10 based products.  Workstations in those days had about that much
compute (1 mip, roughly).  We used the larger 11/750's alot mostly because
we had big disks attached to them (big being 80 megabytes).

> > We run the kdrive X server on iPAQ PDA's and others, which, depending
> > on the model, have 16, 32, or 64 meg of RAM.  The X server is well under
> > 1 megabyte in size, including Render and a number of other extensions;
> > when running it takes maybe 2 megabytes RAM.  We could go much further
> > in reducing the footprint if we needed to, but it doesn't seem worthwhile
> > right now as the big offenders are toolkit and applications, not X itself.
> It kind of underlines my point, though, that it took handheld devices to get
> kdrive started.  While from what I can see, the interest in kdrive is as
> least as much for *desktop* use.  And certainly not because desktop hardware
> is constrained, but simply because it makes sense and appeals to people.

Kdrive predates handhelds.  It was, however, targetted at embedded use.

> Meanwhile....why would it not be worthwhile to reduce the footprint further
> in *anticipation* of libraries and applications?

We certainly have been working on footprint issues.  But kdrive lacks 
a fair amount of infrastructure quite desirable for desktop use: in 
particular, the loadable drivers. It does have a very different design 
center: embedded use, and essentially no configurability.  This is both 
a major feature, and a bug.

> > The one thing we're expermenting with right now is using mallopt to
> > allow the X server to return more VM to the operating system from pixmap
> > use: better yet would be to probably separate pixmap storage in the server
> > from the general heap and do a compacting GC on pixmap storage.
> Hmm, last I looked, both the X server and glibc had mallocs that use mmap()
> for allocations larger than a certain threshold, rather than the heap.  Of
> course, pixmaps vary greatly in size....

Yes; I'm experimenting in making that value smaller.  By default, malloc
in glibc uses something like 128kbytes IIRC.  But if the region
code used for windowing ops runs into this limit, windowing computations
become *way* too slow, so one can't just crank it down arbitrarily.

> I think you mention offscreen VRAM in another post.
> Pixmaps aren't shared between apps the way fonts are, despite the fact that
> lately many apps use XPM and what amounts to "pixmaps from files".  Then
> again, apps tend not to use the same pixmaps, so it probably wouldn't help
> much even if they could share them.

Their semantics are that they are drawable: one could do a cryptographic
hash on them and copy on write, I suppose.  We'd have to do some research
to see if the sharing is common enough to be worth the investment.
My intuition is it won't help much, that most pixmaps are unique
to a given application: I'd be happy to be proven wrong.

> > Various stuff has bloated over the years, but it is generally on the
> > applications side.  Sometimes you think the X server is bloating, when it
> > is really that applications have a pixmap leak, for example.  If your
> > application asks the X server to store a 4 megabyte image in it, it
> > obediently does so.  This isn't X's fault, but the application's request;
> > fix the busted application....
> Or the busted kernel, in the case of the old Mach VM in BSD.
> I went to fetch KDE and GNOME, and changed my mind.  But you *must* run some
> form of Mozilla in order to access all the crazy Web sites, and that baby is,
> well, dunno what to say.  Netscape 6 seems to have a memory leak of *some*
> kind; it develops progressive thrash, irrespective of cache.  (After this, I
> have an aversion to hassling for anything more recent.)

You'd be wise to update to a curren mozilla, which behaves *much* better
than Netscape 6.

> Sigh.  For a while there, before the Windows 95 crowd, I could mostly run
> Chimera.  And I thought Netscape at 1.2M on Windows 3.1 was bloated.

Bloat is in the eye of the beholder, (un)fortunately.  Developing better
tools to enable application and toolkit developers to understand where
they are using memory would be a great help.  

The new XRes extension (which I believe Mark V. wrote, IIRC) is a start, 
but we need applications to visualize this so that desktop developers 
understand what they are doing.

The Xres extension was very useful to us on handhelds within the last 
month in tracking down who was leaking pixmaps (turned out that while 
the web browser we were using (dillo) was somewhat a problem, our window 
manager and screen keyboard application were the major culprit). The moral 
is that the bloat may not be where you think it is, and that most application 
developers don't understand the consequences of what they ask X to do.

If someone could make this new extension really useful to toolkit and 
app developers, by building an easy to use tool for visualizing memory 
usage used by clients, it would be a major blow against bloat.  But
saying X itself, or the XFree86 version of the server is at fault,
is laying (most of) the blame in the wrong direction.  For a long time,
IBM was running the full XFree86 server on their Linux watch..... 

Care to write some code to complete the Xres work and make it really
useful to journeyman programmers?  

A new tool and methodology Keith Packard and I are developing right now 
for our Usenix paper enables one to much more easily see the performance 
consequences of toolkits and applications at the protocol level; but that 
doesn't directly address memory usage.  When we have something for people 
to play with (probably next week), we'll post a pointer.

				- Jim

Jim Gettys
Cambridge Research Laboratory
HP Labs, Hewlett-Packard Company

[X.Org]     [XFree86]     [XFree86 Discussion]     [XFree86 Newbie]     [IETF Annouce]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Samba]     [Linux Security]     [Linux RAID]     [Linux Resources]

  Powered by Linux