public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "a dot darovskikh at compassplus dot ru" <sourceware-bugzilla@sources.redhat.com>
To: glibc-bugs@sources.redhat.com
Subject: [Bug libc/207] ucontext is very slow.
Date: Wed, 09 Jun 2004 04:31:00 -0000	[thread overview]
Message-ID: <20040609043101.28565.qmail@sourceware.org> (raw)
In-Reply-To: <20040607084537.207.a.darovskikh@compassplus.ru>


------- Additional Comments From a dot darovskikh at compassplus dot ru  2004-06-09 04:30 -------
Subject: Re:  ucontext is very slow.

On Tuesday 08 June 2004 20:38, jakub at redhat dot com wrote:
> ------- Additional Comments From jakub at redhat dot com  2004-06-08 14:38
> ------- Hardly.
> More than 50% of the time is spent in sigprocmask syscalls, which are
> needed (the program can change its signal mask any time and this needs to
> be preserved, caching current signal mask in userland would be a huge can
> of problems and slowdowns for little gain).
> The other big part of the total time is spent on saving/restoring FPU state
> (again, swapcontext must do this) and that's about it.
>
> Why aren't you using real threads instead?

This is because we use thousands so-called "tasks", which access on the same 
"tree". If we implement it using real threads, they will use complex 
synchronization, which will take much more time than the real work. This is 
why we need cooperative multitasking. There are some more complex reasons for 
this, so I'm afraid, we will not able to use real threads. Indeed, we do use 
it, but it's for external things, like database connections.

Is it possible to avoid sigprocmask syscalls and FPU things? We do not use it.

Maybe it's possible to take this code and remove those calls from it? Or use 
something like setjmp/longjmp? I tried last one, but timings were even worse.

Alexander Darovsky.


-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=207

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


  parent reply	other threads:[~2004-06-09  4:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-07  8:45 [Bug libc/207] New: " a dot darovskikh at compassplus dot ru
2004-06-07  8:47 ` [Bug libc/207] " a dot darovskikh at compassplus dot ru
2004-06-07  8:48 ` a dot darovskikh at compassplus dot ru
2004-06-08 14:57 ` jakub at redhat dot com
2004-06-09  4:31 ` a dot darovskikh at compassplus dot ru [this message]
2004-08-10  2:06 ` drepper at redhat dot com

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=20040609043101.28565.qmail@sourceware.org \
    --to=sourceware-bugzilla@sources.redhat.com \
    --cc=glibc-bugs@sources.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).