harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm] stress.Mix / MegaSpawn threading bug
Date Thu, 11 Jan 2007 19:53:40 GMT
On 1/11/07, Salikh Zakirov <Salikh.Zakirov@intel.com> wrote:
>
>
> >> >> 2)
> >> > >> Why not simply hard code DRLVM to throw an OOME whenever there
are
> >> > >> more than
> >> > >> 1K threads running?  I think Rana first suggested this approach.
> >> > >> My guess
> >> > >> is that 1K threads is good enough to run lots of interesting
> >> > >> workloads.  My
> >> > >> guess is that common versions of WinXP and Linux will handle the
C
> >> > >> malloc()
> >> > >> load of 1K threads successfully.  If not, how about trying 512
> >> > >> threads?
>
> I've tried a quick-and-dirty patch to limit the number of threads to 500,
> and it indeed fixes crashes on MegaSpawn.


This is good news.  Thanks for trying this out.  One question.  Does DRLVM
handle OOME properly and gracefully when threads are limited to 500?


> -1 for hard coding max number of threads.
>
> Alexey's proposal to watch virtual memory availability looks feasible,
> and will let us avoid hardcoding any number.
>
> My observation is that limiting number of concurrently running threads
> is by far easier than implementing some sort of custom memory manager
> with reserve areas etc, and will allow us to get over MegaSpawn failures.


One pitfall to avoid is second guessing how malloc() behaves when there is
limited virtual memory available.  In specific, malloc() may want to grab
50MB of virtual space but the OS only has  eighteen 45MB chunks or smaller
available.  And, of course, malloc/OS behavior varies from platform to
platform.  A simpler, easier to debug, maintain approach for right now would
be to set a hard limit.






-- 
Weldon Washburn
Intel Enterprise Solutions Software Division

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message