From: Benjamin Marzinski <bmarzins@redhat.com>
To: device-mapper development <dm-devel@redhat.com>
Subject: Re: [PATCH 2/3] set pthread stack size to at least PTHREAD_STACK_MIN
Date: Mon, 30 Mar 2009 18:30:05 -0500 [thread overview]
Message-ID: <20090330233005.GL15911@ether.msp.redhat.com> (raw)
In-Reply-To: <95d3ae170903170056l467c50c1v40a3657f001030e3@mail.gmail.com>
On Tue, Mar 17, 2009 at 07:56:39AM +0000, Joe Thornber wrote:
> 2009/3/16 Benjamin Marzinski <bmarzins@redhat.com>:
> > I definitely see a problem if we use the default stacksize on ia64
> > machines. In RHEL5 at least, it's 10Mb per thread. With one waiter
> > thread per multipath device, you get a gigabyte of memory wasted on
> > machines with over a hundred multipath devices.
>
> You need to check whether this is 1G of physical memory, or just a 1G
> chunk out of the address space.
>
> Some threads need to have their stack reserved and locked into memory
> before calls into the kernel. This avoids deadlocks where the stack
> gets paged out, but he vm can't page it back in until the thread
> completes ...
>
> It sounds like you have many more threads running these days than when
> I last looked at LVM, it's not clear to me how many of these are ones
> that need their stacks mem-locking. Do you have an idea ?
>
> If they don't need mem-locking then as long as you're not forcing the
> stack to be physically allocated I wouldn't worry too much about
> consuming address space.
>
> Hope that ramble made sense,
Yeah, sorry for missing your reply.
The issue is that the event threads occasionally need to hold mutexs
that the checker thread (the one that restores downed paths) needs. If
the system was low on memory because a number of devices had no paths to
them, and IO was queueing up, you could run into a problem where a event
thread was paged out while holding a mutex. With the mutex locked, the
checker thread could never restore the downed paths, letting the IO
complete, and freeing up the memory.
Christophe, if people are O.k. with these patches now, could they get
in.
Thanks
-Ben
>
> - Joe
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2009-03-30 23:30 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-12 18:38 [PATCH 0/3] Some miscellaneous dm-multipath patches Benjamin Marzinski
2009-03-12 18:38 ` [PATCH 1/3] remove deleted path from pathvec Benjamin Marzinski
2009-03-12 18:38 ` [PATCH 2/3] set pthread stack size to at least PTHREAD_STACK_MIN Benjamin Marzinski
2009-03-13 10:51 ` Hannes Reinecke
2009-03-13 20:55 ` Benjamin Marzinski
2009-03-16 16:12 ` Hannes Reinecke
2009-03-16 23:08 ` Benjamin Marzinski
2009-03-17 7:56 ` Joe Thornber
2009-03-30 23:30 ` Benjamin Marzinski [this message]
2009-03-13 11:08 ` Joe Thornber
2009-03-12 18:38 ` [PATCH 3/3] Add options to multipathd to turn off queueing Benjamin Marzinski
2017-04-25 13:38 ` Xose Vazquez Perez
2017-04-25 18:03 ` Benjamin Marzinski
2009-04-03 22:40 ` [PATCH 0/3] Some miscellaneous dm-multipath patches Christophe Varoqui
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090330233005.GL15911@ether.msp.redhat.com \
--to=bmarzins@redhat.com \
--cc=dm-devel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.