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

List:       opensolaris-discuss
Subject:    Re: [osol-discuss] [desktop-discuss] Poor interactive performance
From:       Bart Smaalders <bart.smaalders () Sun ! COM>
Date:       2009-02-28 1:24:26
Message-ID: 49A8924A.9000602 () Sun ! COM
[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.   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.
> 

What is needed is allocation technology that doesn't muck w/ the process
address space because that's expensive for long-running processes that
have migrated to every cpu on the box; you end up cross-calling lots of
other cpus, and if your clients do stupid allocation behaviors the
cross call rate goes through the roof.  On the other hand, if the pages
are no longer interesting, writing them out to swap and paging them back
in isn't very interesting either.

What may be a useful experiment is using

	madvise(caddr_t addr, size_t len, MADV_FREE)

on large deallocated pixmaps:

      MADV_FREE              Tell the kernel that contents in  the
                             specified address range are no longer
                             important  and  the  range  will   be
                             overwritten. When there is demand for
                             memory, the system  will  free  pages
                             associated with the specified address
                             range. In  this  instance,  the  next
                             time  a  page in the address range is
                             referenced,  it  will   contain   all
                             zeroes.   Otherwise,  it will contain
                             the data that was there prior to  the
                             MADV_FREE  call.  References  made to
                             the address range will not  make  the
                             system  read from backing store (swap
                             space) until  the  page  is  modified
                             again.
- Bart


-- 
Bart Smaalders			Solaris Kernel Performance
barts@cyber.eng.sun.com		http://blogs.sun.com/barts
"You will contribute more with mercurial than with thunderbird."
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
[prev in list] [next in list] [prev in thread] [next in thread]