August 2007 - Darwin-dev - lists.apple.com

pthread_create blocks calling thread
by Paul Nelson 31 Aug '07

31 Aug '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thread-index: AcfsCuwzKqG2nlf+Edy/9wAWy4i6sA== Thread-topic: pthread_create blocks calling thread User-agent: Microsoft-Entourage/11.3.6.070618 Under what circumstances could pthread_create block the calling thread? I'm debugging a problem where pthread_create does not return. TIA, Paul Nelson _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Poor performance of pthreads across cpu dies.
by Andrew Gallatin 31 Aug '07

31 Aug '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Michael Smith writes: > On Aug 30, 2007, at 12:04 PM, darwin-dev-request(a)lists.apple.com wrote: > > > I've seen similar issues benchmarking 10GbE NICs, and I don't even > > need pthreads. The scheduler tends to run the user mode application > > on one core, the interrupt handler kernel thread (iokit "workloop") on > > another, and the network stack (dlil) kernel thread on yet another. > > In and of itself, this is not an issue. More of a problem is that, > in many cases, the threads you have noted above don't stay in the > same cache domain. This *is* an issue. > > > II think the fundamental problem is the scheduler doesn't have a clue > > about cpu affinity, and MacOSX is lacking any APIs or command line > > interfaces that would allow the app or admin to give it a clue (like > > you can on Linux, Solaris, etc). > > It is naive to assume, particularly in the context of a heavily > threaded system like MacOS, that thread:CPU affinity will yield > significant improvements here. It is perhaps more naive to presume that it won't. My 10GbE driver work makes me pretty familiar with the behavior under load of the network stacks in MacOSX, Linux, Solaris, and to a lesser Windows, all of which allow hinting. If you take another OS (say Linux), and intstall it on a Mac Pro, the only way to make it perform badly (like MacOSX) is to supply totally *incorrect* hints (bind the irq handler to one socket, and the benchmark to the other). And even then it does not perform as badly as MacOSX does on average :( If I then boot into OSX and apply the only sort of hinting I'm aware of -- disabling the second CPU package -- I get "reasonable" performance (2x the CPU utilization of Linux, and a hair less bandwidth). If I had a way to bind the ithread, the dlil thread, and the application to a CPU or set of CPUs, I could coerce MacOSX into getting decent performance without the drastic step of disabling a CPU core. > The critical issue, as I note above, is not CPU affinity but rather > cache affinity, and more specifically data:cache affinity, since the > penalty is not cache load times as the threads move around (since the > caches in question are typically large enough to hold the thread > working set for each thread in play), but snoop/flush/reload time as > dirty data moves (slowly) from one cache domain to another as it is > handed off from one thread to the next. Indeed. > > Good would be a scheduler with some > > notion of CPU affinity, and better would be a scheduler that allowed > > the user to give it some hints. > > History suggests that this sort of hinting is a mixed blessing, often > generating more problems than it solves (c.f. the NT stack binding > vs. user comprehension for example). It is better to enable a user with a clue to fix something that to prevent a user without a clue from shooting himself in the foot.. > The real challenge involves solving, for some reduced set of > circumstances, the very difficult but related questions: > > o What is the system going to do next? > (e.g. should I schedule a thread that has just become runnable, or > wait in the hope that the current thread will block soon?) > > o Who will want this data (that I have not yet examined or begun > to process) next, and where are they now? > (e.g. should I move this current thread to a different cache domain > so that the consumer will not have to snoop it over?) > > In some restricted, single-activity cases, brute-force hinting > approaches can help with the above. Sadly, hinting works much less > well once you have more than one source of hints, or more than one > topology in play, or a topology that is not understood by the hinter; > an adaptive and automatic solution is much more attractive in that case. > > I don't think there's any disagreement that the current situation > isn't very good; merely that the proposed 'solutions' fall fairly > well short and that something better is really needed. I'm still of the opinion that something is better than nothing. Even if it is flawed, it can't be worse than the current situation and could be beneficial. Since you guys are fond of Solaris these days (Dtrace, ZFS, etc), I encourage you to take a look at the tools and APIs that Solaris provides (psrset(1M), processor_bind(2), pset_bind(2). Drew _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Please ignore (Re: IP address change events?)
by Rustam Muginov 31 Aug '07

31 Aug '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: IP address change events?
by Rustam Muginov 31 Aug '07

31 Aug '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

IP address change events?
by Terry Simons 31 Aug '07

31 Aug '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hi, - Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Are there any OS-level events generated when an IP address changes on Mac OS X? This email sent to site_archiver(a)lists.apple.com

1 0

Re: Poor performance of pthreads across cpu dies.
by Michael Smith 31 Aug '07

31 Aug '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Aug 30, 2007, at 12:04 PM, darwin-dev-request(a)lists.apple.com wrote: I've seen similar issues benchmarking 10GbE NICs, and I don't even need pthreads. The scheduler tends to run the user mode application on one core, the interrupt handler kernel thread (iokit "workloop") on another, and the network stack (dlil) kernel thread on yet another. II think the fundamental problem is the scheduler doesn't have a clue about cpu affinity, and MacOSX is lacking any APIs or command line interfaces that would allow the app or admin to give it a clue (like you can on Linux, Solaris, etc). Good would be a scheduler with some notion of CPU affinity, and better would be a scheduler that allowed the user to give it some hints. = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Without wanting to rehash decades worth of research and hundreds of papers and experiments on the topic that comprise the body of experience on this subject, a couple of points are worth making. In and of itself, this is not an issue. More of a problem is that, in many cases, the threads you have noted above don't stay in the same cache domain. This *is* an issue. It is naive to assume, particularly in the context of a heavily threaded system like MacOS, that thread:CPU affinity will yield significant improvements here. The critical issue, as I note above, is not CPU affinity but rather cache affinity, and more specifically data:cache affinity, since the penalty is not cache load times as the threads move around (since the caches in question are typically large enough to hold the thread working set for each thread in play), but snoop/flush/reload time as dirty data moves (slowly) from one cache domain to another as it is handed off from one thread to the next. History suggests that this sort of hinting is a mixed blessing, often generating more problems than it solves (c.f. the NT stack binding vs. user comprehension for example). The real challenge involves solving, for some reduced set of circumstances, the very difficult but related questions: o What is the system going to do next? (e.g. should I schedule a thread that has just become runnable, or wait in the hope that the current thread will block soon?) o Who will want this data (that I have not yet examined or begun to process) next, and where are they now? (e.g. should I move this current thread to a different cache domain so that the consumer will not have to snoop it over?) In some restricted, single-activity cases, brute-force hinting approaches can help with the above. Sadly, hinting works much less well once you have more than one source of hints, or more than one topology in play, or a topology that is not understood by the hinter; an adaptive and automatic solution is much more attractive in that case. I don't think there's any disagreement that the current situation isn't very good; merely that the proposed 'solutions' fall fairly well short and that something better is really needed. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Getting LOGNAME when using sudo
by James Peach 31 Aug '07

31 Aug '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=U9Syqga9iWdKpcA8ie1S57rNe1vMiy2fPpPlwyMY2CbH8Zt9ioZtamZ4kdH9NY1xrrFhDl2QZ4khoJ3XpJx5rU2Xnh0OyRP/DNr5yYi+GXeDuXbDDZZckU82obQICgbZzXY7CF9uEPOq07wcWeUudP/2e5evR0c8H1fn5piikK4= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CSCPij4fIueK8IIDUEm6qP+kaxjuiEaVFboKQ/g5eTzXcgxbXHM9BHs8UAz6QlfZ43eFflbgIdGRk2zZpZu5p7SDQ7G2MK+f797iCazp5MxCiM5xC+VKs/XioHmviGLJGndp0PtfLP+VtxixhdnwJEDENgQ5dydvZ5vo88r+p1A= On 30/08/2007, Mike <lists(a)michael-amorose.com> wrote: > I have a shell script that needs to get the LOGNAME env variable. But I > need to run my script using sudo which apparently causes LOGNAME to > incorrectly be set to "root". > > How can can I get the logged in user's name even when running a script > using sudo? > > I need to get the user name because I need to build shell path to the > current user's desktop and only the exact logged in user's name will work. >From sudo(8): ENVIRONMENT ... SUDO_USER Set to the login of the user who invoked sudo -- James Peach | jorgar(a)gmail.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Getting LOGNAME when using sudo
by Mike 31 Aug '07

31 Aug '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Thunderbird 2.0.0.6 (Macintosh/20070728) Thanks, Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I have a shell script that needs to get the LOGNAME env variable. But I need to run my script using sudo which apparently causes LOGNAME to incorrectly be set to "root". How can can I get the logged in user's name even when running a script using sudo? I need to get the user name because I need to build shell path to the current user's desktop and only the exact logged in user's name will work. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Poor performance of pthreads across cpu dies.
by Andrew Gallatin 30 Aug '07

30 Aug '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Jonas Maebe writes: > > On 30 Aug 2007, at 00:55, Andrew Gallatin wrote: > > > I think the fundamental problem is the scheduler doesn't have a clue > > about cpu affinity, and MacOSX is lacking any APIs or command line > > interfaces that would allow the app or admin to give it a clue (like > > you can on Linux, Solaris, etc). > > CHUD contains such an api (utilBindThreadToCPU), but it's > undocumented and therefore only suitable for experimenting. Cool. I didn't know that. CHUD has lots of good stuff that isn't documented / public. I'd love to be able to figure out the PCI config space access stuff that it has. Drew _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Poor performance of pthreads across cpu dies.
by Jonas Maebe 30 Aug '07

30 Aug '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 30 Aug 2007, at 00:55, Andrew Gallatin wrote: I think the fundamental problem is the scheduler doesn't have a clue about cpu affinity, and MacOSX is lacking any APIs or command line interfaces that would allow the app or admin to give it a clue (like you can on Linux, Solaris, etc). Jonas _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… CHUD contains such an api (utilBindThreadToCPU), but it's undocumented and therefore only suitable for experimenting. This email sent to site_archiver(a)lists.apple.com

1 0