[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-discuss
Subject:    [osol-discuss] Using |mmap()| for Xorg pixmap allocations... / was:
From:       Roland Mainz <roland.mainz () nrubsig ! org>
Date:       2009-02-28 2:40:02
Message-ID: 49A8A402.46149B63 () nrubsig ! org
[Download RAW message or body]

Alan Coopersmith wrote:
> Joerg Schilling wrote:
> > Another issue: Xsun did use mmap() to allocate bigger parts of memory in the
> > X server. If big memory leaking program like netscape died in former times,
> > Xsun did shrink. Today, we have firefox that itself allocates less memory than
> > before but rather forxes X to allocate more memory and Xorg is malloc() based
> > and this does not shrink when fireforx dies.......
> 
> We had to turn down Xsun's use of mmap() because it caused performance problems
> when programs like Netscape or the GNOME desktop had allocated hundreds of
> pixmaps per session, and you had dozens of sessions running on a Sun Ray server
> leading to TLB thrashing for all those new page mapping entries, especially on
> the UltraSPARC CPU's with small TLBs.

Right - but that was a problem of not limiting the minimum amount for
|mmap()|'ed pixmaps. AFAIK later this was changed to 1MB which is far
too large to be usefull (as suggested in the original thread I suggested
AFAIK a size of 8*pagesize as minimum threshhold to get a good balance
between extra overhead, TLB usage (on UltraSPARC-2 CPUs) and pixmap
create/destroy performance) except for large double-buffer pixmaps as
used by Mozilla/FireFox/Seamonkey/etc.

> There were also performance issues with
> pixmap allocation & deallocation becoming much more expensive, since
> mmap/mmunmap are far more expensive calls than malloc/free.   (See for instance,
> the GNOME stock ticker issue described in the original DTrace Usenix paper,
> and http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4757131 )
> 
> Even so, we've looked at porting those changes to Xorg before, and I released
> the Xsun code to Roland at one point when he volunteered to port it, but have
> never gotten it done.

If I recall it correctly the code was working except if something starts
to use MIT-SHM - AFAIK this turned the simple patch into a compliciated
mess which required to change the Xorg ABI and that was a "no go" during
that time.

BTW: A simpler and faster solution may be to let Xorg use the libast
allocator using the |mmap()| backend since it "bundles" smaller
allocation into larger |mmap()| ones (again 8*pagesize but this is a
tuneable) and avoids long-term memory fragmentation (better than the
libc code) which helps a _lot_ with Xorg.

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
[prev in list] [next in list] [prev in thread] [next in thread]