From: Blaisorblade <blaisorblade_spam@yahoo.it> To: user-mode-linux-devel@lists.sourceforge.net Cc: Jeff Dike <jdike@addtoit.com>, linux-kernel@vger.kernel.org, cw@f00f.org Subject: Re: Synchronization primitives in UML (was: Re: [uml-devel] Re: [patch 09/20] uml: use SIG_IGN for empty sighandler) Date: Tue, 9 Nov 2004 20:15:10 +0100 [thread overview] Message-ID: <200411092015.10544.blaisorblade_spam@yahoo.it> (raw) In-Reply-To: <200411092048.iA9Kmjg9004223@ccure.user-mode-linux.org> On Tuesday 09 November 2004 21:48, Jeff Dike wrote: > blaisorblade_spam@yahoo.it said: > > I also understand now what all this is for. When I have time for this, > > I'll at least copy and paste your mail into a comment, with any > > needed adjustment. > That would be a good idea. > > For the semaphore issue, I have some ideas (like using futexes) which > > need to be developed a bit: > > 1) I want to create a semaphore API in os_*. > > 2) It will be able to use socketpairs. > > 3) It will be able to use futexes, if they are > > non-persistant and usable without too much issues (the same way we > > are going to support Async I/O). > > 4) It will be used first by the code > > which could really benefit from the performance increase. > > 5) It won't > > use persistant objects. > This all sounds good, although there are simplicity benefits to just using > one underlying mechanism, as long as there are no overriding disadvantages > to it. Yes, I would like that, too, but futexes are 2.6 only, and probably also NPTL-only (we are going to fix that, at least for SKAS mode), but faster than anything else. Nothing apart this. > > Any comment on these issues? Also, apart TT context switching, is > > there any other performance-sensitive use of semaphores, which would > > benefit from using futexes? > Offhand, I think context switching is the most sensitive one. Ok. But to get TT mode to work against NPTL glibc, which is required for futexes, we need to recode the "thread_private" section in uml.lds.S to work with NPTL glibc. It seems that binutils does not like that (the error is "not enough program header allocated", which refers to the fact that SIZEOF_HEADERS is guessed and then used. Not using SIZEOF_HEADERS could help, if doing this is possible). > > Yes, semget and friends are uglier. > > But don't think that the current nested code is simple to read - three > > semaphores at a time, without a clear name, are not the clearer code > > on the world. > What nested code are you talking about? There are two down() and two up(); additionally, run_helper_thread() manages at least another pipe(). I don't see an easy way to simplifying all this, but it's needed (or at least some comment should be added). Just a cleanup, anyway. -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729
WARNING: multiple messages have this Message-ID (diff)
From: Blaisorblade <blaisorblade_spam@yahoo.it> To: user-mode-linux-devel@lists.sourceforge.net Cc: Jeff Dike <jdike@addtoit.com>, linux-kernel@vger.kernel.org, cw@f00f.org Subject: Re: Synchronization primitives in UML (was: Re: [uml-devel] Re: [patch 09/20] uml: use SIG_IGN for empty sighandler) Date: Tue, 9 Nov 2004 20:15:10 +0100 [thread overview] Message-ID: <200411092015.10544.blaisorblade_spam@yahoo.it> (raw) In-Reply-To: <200411092048.iA9Kmjg9004223@ccure.user-mode-linux.org> On Tuesday 09 November 2004 21:48, Jeff Dike wrote: > blaisorblade_spam@yahoo.it said: > > I also understand now what all this is for. When I have time for this, > > I'll at least copy and paste your mail into a comment, with any > > needed adjustment. > That would be a good idea. > > For the semaphore issue, I have some ideas (like using futexes) which > > need to be developed a bit: > > 1) I want to create a semaphore API in os_*. > > 2) It will be able to use socketpairs. > > 3) It will be able to use futexes, if they are > > non-persistant and usable without too much issues (the same way we > > are going to support Async I/O). > > 4) It will be used first by the code > > which could really benefit from the performance increase. > > 5) It won't > > use persistant objects. > This all sounds good, although there are simplicity benefits to just using > one underlying mechanism, as long as there are no overriding disadvantages > to it. Yes, I would like that, too, but futexes are 2.6 only, and probably also NPTL-only (we are going to fix that, at least for SKAS mode), but faster than anything else. Nothing apart this. > > Any comment on these issues? Also, apart TT context switching, is > > there any other performance-sensitive use of semaphores, which would > > benefit from using futexes? > Offhand, I think context switching is the most sensitive one. Ok. But to get TT mode to work against NPTL glibc, which is required for futexes, we need to recode the "thread_private" section in uml.lds.S to work with NPTL glibc. It seems that binutils does not like that (the error is "not enough program header allocated", which refers to the fact that SIZEOF_HEADERS is guessed and then used. Not using SIZEOF_HEADERS could help, if doing this is possible). > > Yes, semget and friends are uglier. > > But don't think that the current nested code is simple to read - three > > semaphores at a time, without a clear name, are not the clearer code > > on the world. > What nested code are you talking about? There are two down() and two up(); additionally, run_helper_thread() manages at least another pipe(). I don't see an easy way to simplifying all this, but it's needed (or at least some comment should be added). Just a cleanup, anyway. -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
next prev parent reply other threads:[~2004-11-09 19:14 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top 2004-11-05 19:36 Synchronization primitives in UML (was: Re: [uml-devel] Re: [patch 09/20] uml: use SIG_IGN for empty sighandler) Blaisorblade 2004-11-05 19:36 ` Blaisorblade 2004-11-06 5:13 ` Jeff Dike 2004-11-06 5:13 ` Jeff Dike 2004-11-09 17:44 ` Blaisorblade 2004-11-09 20:48 ` Jeff Dike 2004-11-09 20:48 ` Jeff Dike 2004-11-09 19:15 ` Blaisorblade [this message] 2004-11-09 19:15 ` Blaisorblade 2004-11-09 19:41 ` Synchronization primitives in UML Chris Friesen 2004-11-09 19:41 ` [uml-devel] " Chris Friesen
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=200411092015.10544.blaisorblade_spam@yahoo.it \ --to=blaisorblade_spam@yahoo.it \ --cc=cw@f00f.org \ --cc=jdike@addtoit.com \ --cc=linux-kernel@vger.kernel.org \ --cc=user-mode-linux-devel@lists.sourceforge.net \ /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: linkBe 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.