On Fri, Jun 09, 2006 at 06:47:11AM +0800, Ge, Xu Dong (Andrew) wrote:
> Hi,
>
> Nice to hear from you. Now I have a further step, and it is interesting.
>
> Since I found the value of DFL is so high in solaris 9, in the beginning of
> my program
> I will allocate enough memory to attach the physical memory, something like:
>
> 493 int main(int ac, char *av[])
> 494 {
> 495 unsigned int length = 2000000000;
> 496 void * cache = malloc(length);
> 497 memset(cache, 0, length);
> 498 sleep(2);
> 499 printf("begin to work in 5 seconds...\n");
> 500 sleep(5);
> 501 free(cache);
> ..............
>
> then I find it is fine.. Seems it is the root cause, however I can not
> understand why the
> DFL is so high, Could you please give me some clue on that?
> Enough memory in my system ( 16G).
This could be a bug in the way the kernel faults in new sbrk(1M)-based heap
pages in Solaris 9, which was fixed in Solaris 10. I'm not a VM system expert,
so it's just a guess.
The data fault rate could explain the high LCK time; if data faults were
occurring often while a lock was held, and took a long time to complete,
other threads would pile up against the lock.
Cheers,
- jonathan
> >-----Original Message-----
> >From: Jonathan Adams [mailto:[EMAIL PROTECTED]
> >Sent: 2006?6?9? 6:30
> >To: Andrew ge
> >Cc: [email protected]
> >Subject: Re: [osol-code] libumem.so does not work well under solaris9?
> >
> >
> >On Thu, Jun 08, 2006 at 12:00:31PM -0700, Andrew ge wrote:
> >> Hi,
> >>
> >> I am now developping an appliaction that frequently allocate
> >big buckets of memory with multiple threads. I used the
> >libumem.so and it works pretty well under solaris 10. However,
> >under solaris 9, it has problem similar with the normal
> >malloc, that is, from stackframe I pasted below, I can see the
> >threads are wait for the lock:
> >> ----- (stack frame for one
> >thread)------------------------------------------------
> >> ff1558f4 lwp_park (0, 0, 0)
> >> ff15166c mutex_lock_queue (ff168b44, 0, ff39c7c0, ff168000,
> >0, 0) + 104
> >> ff15206c slow_lock (ff39c7c0, ff0f0200, 10, ff394000,
> >20e008, 1e7ff0) + 58
> >> ff37b5cc vmem_alloc (ff39c790, 2000, 1, 0, 0, 2000) + fc
> >> ff37b0c0 vmem_xalloc (0, 2000, ff394000, 0, 2044a8, 2) + 554
> >> ff37b6cc vmem_alloc (204478, 2000, 1, 198f7f, 0, 0) + 1fc
> >> ff375af0 umem_slab_create (2000, 0, 8fc54, 0, fef7bb30, 1b73fc) + 5c
> >> ff375ed0 umem_slab_alloc (215188, 0, 0, ff394000, 0, 0) + 90
> >> ff376e48 umem_cache_alloc (0, 0, 0, 0, 0, 0) + ec
> >> ff3772a4 umem_alloc (1394, 0, 0, 0, 0, 0) + 44
> >> ff37354c malloc (138c, 1, 10, 3831da98, 20e008, 1e7ff0) + 2c
> >> ff373610 calloc (138c, 1, 2288, 105cc4, b112c, 2000) + 58
> >> ----------------------------------------------
> >
> >This may just be that the Solaris 9 thread library isn't as
> >efficient as
> >the Solaris 10 thread library. Do you ever free any of these buffers?
> >
> >The patch for:
> >
> >6304072 libumem seems to use more heap than it needs
> >
> >(which should be released fairly soon) should help this somewhat, as it
> >adds a few more caches to the mix.
> >
> >> Also, use prstat -mL, I found the value of DFL and LCK is
> >much bigger than which at solaris 10:
> >> PID USERNAME USR SYS TRP TFL DFL LCK SLP LAT VCX ICX SCL
> >SIG PROCESS/LWPID
> >> Prstat -mL at solaris 9:
> >> 2989 xxx 16 21 0.0 0.0 37 23 0.2 2.2 1K 606 6K 0 app/3
> >> 2989 xxx 16 20 0.0 0.0 36 25 0.2 3.2 1K 559 6K 0 app/2
> >> 2989 xxx 15 21 0.0 0.0 37 23 0.2 3.4 1K 611 6K 0 app/4
> >> 2989 xxx 16 20 0.0 0.0 33 28 0.2 2.7 1K 553 6K 0 app/5
> >> Prstat -mL at solaris 10:
> >> 14428 xxx 35 9.1 0.1 0.0 0.6 1.4 51 3.4 1K 1K 25K 0 app/4
> >> 14428 xxx 33 8.8 0.2 0.0 0.3 1.4 53 3.4 1K 1K 23K 0 app/2
> >> 14428 xxx 32 8.5 0.2 0.0 0.4 1.3 53 4.5 1K 1K 23K 0 app/5
> >> 14428 xxx 32 8.3 0.1 0.0 0.4 1.5 53 4.1 1K 1K 23K 0 app/3
> >>
> >> The two machine has the same configruation, exception the version
> >> of solaris. Could anyone give me some clue for that? Need I do some
> >> configuration for libumem.so under solaris 9?
> >
> >Unfortunately, I'm not sure there's an available configuration
> >variable which
> >would help.
> >
> >Cheers,
> >- jonathan
> >
> >--
> >Jonathan Adams, Solaris Kernel Development
> >
--
Jonathan Adams, Solaris Kernel Development
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
