On Mon, May 11, 2009 at 06:42:55PM -0500, Bob Friesenhahn wrote: > On Mon, 11 May 2009, johan...@sun.com wrote: >> >> I'm not entirely convinced that this is simply the difference between >> memory mapped allocations versus sbrk allocations. If you compare the >> numbers between malloc and umem, notice that the overall increase in >> real time is due to the extra 5 seconds spent in user time in umem. > > Yes, but the user time is virtually the same between -lumem and > -lmapmalloc. It seems to me that if the application incurs a page fault > that part of that page fault may be attributed to user time and the rest > is not attributed to the process at all.
I'm not disagreeing that the user time between umem and mapmalloc is very similar. However, page-fault time should be attributed as system time. Chad Mynhier recently putback some improvements to ptime(1), that show information about the microstate accounting data that each process keeps. That information contains not only usr and sys, but trap, text and data fault, and a bunch of other information. If you want to get this data, try the experiments again using ptime(1) -m. >> However, mapmalloc increases both the system and user time when compared >> to malloc. > > Yes. User time with mapmalloc is the same as umem, but system time is > somewhat increased. Libumem allows you to choose which backend is used for the vmem layer by setting backend=sbrk or backend=mmap in UMEM_OPTIONS in the environment, provided that you're not using it in standalone mode. I'm not certain what the difference is, but I assume that compiling -lumem isn't considered standalone. I could be wrong about that. >> There have been some past discussions on this list about identifying >> problems with memory allocations, and applications that allocate memory >> inefficiently. If your application is performing a lot of small memory >> allocations, it's possible that you're seeing poor performance for that >> reason. > > Yes. I don't know what libjpeg itself does, but GraphicsMagick should > be performing a similar number of allocations (maybe 1000 small > allocations) regardless of the size of the JPEG file. There are some known issues with small allocations on Solaris. I think I included a bug-id in the e-mail pointer I sent you before. >> I would take a look at how your application is allocating memory, and >> where it's spending its time in these two different libraries. That >> might shed some light on what the problem is. > > SPOT says that most time is spent executing libjpeg code (primarily > ycc_rgb_convert) and that there is quite a lot of application stall with > "LD/ST Unit Full" at a wopping 49.7%. When using -lumem, the program > seems to spend 45% of the time waiting. This is definitely not the case > for the rest of GraphicsMagick. I'm not sure I completely understand. What happens the rest of the time in GraphicsMagick? -j _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
