Thanks for catching that. I'll take a look and commit a fix real
soon now.
Brian
On Dec 8, 2005, at 11:03 AM, Gleb Natapov wrote:
On Thu, Dec 08, 2005 at 09:59:46AM -0500, Brian Barrett wrote:
On Dec 8, 2005, at 9:27 AM, Gleb Natapov wrote:
On Wed, Dec 07, 2005 at 10:40:51AM -0500, Brian
On Thu, 8 Dec 2005, Gleb Natapov wrote:
On Wed, Dec 07, 2005 at 10:40:51AM -0500, Brian Barrett wrote:
Hopefully this made some sense. If not, on to the next round of e-
mails :).
This made allot of sense. What is compiled by default now is malloc_hooks
I'll compile ptmalloc and play with it
On Thu, Dec 08, 2005 at 09:59:46AM -0500, Brian Barrett wrote:
> On Dec 8, 2005, at 9:27 AM, Gleb Natapov wrote:
>
> > On Wed, Dec 07, 2005 at 10:40:51AM -0500, Brian Barrett wrote:
> >> Hopefully this made some sense. If not, on to the next round of e-
> >> mails :).
> >>
> > This made allot of
On Dec 8, 2005, at 9:27 AM, Gleb Natapov wrote:
On Wed, Dec 07, 2005 at 10:40:51AM -0500, Brian Barrett wrote:
Hopefully this made some sense. If not, on to the next round of e-
mails :).
This made allot of sense. What is compiled by default now is
malloc_hooks
I'll compile ptmalloc and pla
On Wed, Dec 07, 2005 at 10:40:51AM -0500, Brian Barrett wrote:
> Hopefully this made some sense. If not, on to the next round of e-
> mails :).
>
This made allot of sense. What is compiled by default now is malloc_hooks
I'll compile ptmalloc and play with it and may be then will be the next
roun
On Dec 7, 2005, at 9:44 AM, Gleb Natapov wrote:
On Tue, Dec 06, 2005 at 11:07:44AM -0500, Brian Barrett wrote:
On Dec 6, 2005, at 10:53 AM, Gleb Natapov wrote:
On Tue, Dec 06, 2005 at 08:33:32AM -0700, Tim S. Woodall wrote:
Also memfree hooks decrease cache efficiency, the better solution
w
On Tue, Dec 06, 2005 at 11:07:44AM -0500, Brian Barrett wrote:
> On Dec 6, 2005, at 10:53 AM, Gleb Natapov wrote:
>
> > On Tue, Dec 06, 2005 at 08:33:32AM -0700, Tim S. Woodall wrote:
> >>> Also memfree hooks decrease cache efficiency, the better solution
> >>> would
> >>> be to catch brk() syst
On Dec 6, 2005, at 10:53 AM, Gleb Natapov wrote:
On Tue, Dec 06, 2005 at 08:33:32AM -0700, Tim S. Woodall wrote:
Also memfree hooks decrease cache efficiency, the better solution
would
be to catch brk() system calls and remove memory from cache only
then,
but there is no way to do it for no
On Tue, Dec 06, 2005 at 08:33:32AM -0700, Tim S. Woodall wrote:
> > Also memfree hooks decrease cache efficiency, the better solution would
> > be to catch brk() system calls and remove memory from cache only then,
> > but there is no way to do it for now.
> >
>
> We are look at other options, in
Hello Gleb,
Gleb Natapov wrote:
On Mon, Dec 05, 2005 at 10:23:14AM -0700, Galen M. Shipman wrote:
Also there is a code commented out that enables memory hooks if
leave_pinned is set. Why this code is disabled? Infiniband will
not work correctly in such setup.
There is still some debate about
On Mon, Dec 05, 2005 at 10:23:14AM -0700, Galen M. Shipman wrote:
> > Also there is a code commented out that enables memory hooks if
> > leave_pinned is set. Why this code is disabled? Infiniband will
> > not work correctly in such setup.
> There is still some debate about what will be the default
On Mon, 5 Dec 2005, Gleb Natapov wrote:
This is because there is no "mpool_base" mca (see patch).
This looks good, will apply.
Also there is a code commented out that enables memory hooks if
leave_pinned is set. Why this code is disabled? Infiniband will
not work correctly in such setup.
Ther
This is because there is no "mpool_base" mca (see patch).
Also there is a code commented out that enables memory hooks if
leave_pinned is set. Why this code is disabled? Infiniband will
not work correctly in such setup.
Index: ompi/mca/mpool/base/mpool_base_open.c
13 matches
Mail list logo
