Re: Is it possible to make -lpthread program to use 100% CPU?

From: Alexandre (Alex.Kovalenko_at_verizon.net)
Date: 05/02/04

  • Next message: M. Warner Losh: "Re: Modem + Network in Xircom cards, and maybe others" 
    Date: Sun, 2 May 2004 10:53:10 -0400
To: freebsd-current@freebsd.org

    On Sun, 02 May 2004 00:37:53 -0400
    "Daniel M. Eischen" <eischen@vigrid.com> wrote:

    > Alexandre Sunny Kovalenko wrote:
    > > On Sat, 1 May 2004 14:49:47 -0400 (EDT)
    > > Daniel Eischen <eischen@vigrid.com> wrote:
    > >
    > >
    > >>On Sat, 1 May 2004, Alexandre Sunny Kovalenko wrote:
    > >>
    > >>
    > >>>On Thu, 29 Apr 2004 17:16:21 +0200
    > >>>Ivan Voras <ivoras@fer.hr> wrote:
    > >>>
    > >>>
    > >>>>Alexandre Sunny Kovalenko wrote:
    > >>>>
    > >>>>
    > >>>>>Alternatively, if there is a need to test a patch or time a program
    > >>>>>in this environment, it could easily be accomplished -- it is a non-
    > >>>>>production box.
    > >>>>
    > >>>>Could you turn off Hyperthreading and report any changes?
    > >>>>
    > >>>
    > >>>I have updated my system to the latest CTM mailing on Friday (4/30) morning (EST).
    > >>>This includes version 1.176 of kern_thread.c.
    > >>>
    > >>>I have turned off hyperthreading and got result, which muddles me rather -- try
    > >>>as I might, with -lpthread I could not get past 50% CPU utilization (as reported
    > >>>by 'top') and number of computations per second matching that (number is very
    > >>>close to that for running single-threaded). Top report with thread view enabled
    > >>>shows that both KSE are bound to CPU 0 (if I am interpreting C column properly).
    > >>
    > >>Are you using system or process scope threads?
    > >>
    > >>--
    > >>Dan Eischen
    > >
    > > Sorry, should have mentioned that too. For -lthr PTHREAD_SCOPE_PROCESS is only
    > > available option. For -lpthread I have tried both, and results do not differ
    > > much, which is what I expect on the machine that runs nothing else (unless
    > > I do not understand PTHREAD_SCOPE_ option).
    >
    > You need to use PTHREAD_SCOPE_SYSTEM in order to get another
    > scheduling quantum (kse group) for each thread under libpthread.
    > There's no way yet to tell the kernel which CPU should get
    > each thread, so they may be scheduled on the same CPU.
    >
    > What scheduler are you using?
    >
    > --
    > Dan Eischen
    >
    > _______________________________________________
    > freebsd-current@freebsd.org mailing list
    > http://lists.freebsd.org/mailman/listinfo/freebsd-current
    > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

    I did mention this one ;) With older sources (kern_thread.c 1.175) I have tried
    both with the similar results. With the last update (last CTM from EST morning
    on Friday 4/30) I only tried _ULE. If you need me to try _4BSD, let me know.

    Just out of curiosity, if I have 64 threads and 4 CPUs would not result be the
    same with PTHREAD_SCOPE_SYSTEM and PTHREAD_SCOPE_PROCESS, since I could not
    get more KSEGs then I have CPUs, and default is 8 threads per KSEG? Or am I
    totally off the mark? 

    -- 
Alexandre "Sunny" Kovalenko.
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
  • Next message: M. Warner Losh: "Re: Modem + Network in Xircom cards, and maybe others"

    Relevant Pages

    • Re: Gurus, a silly question for preemptive behavior
      ... however, linux kernel is NOT ... my application causes CPU pegging. ... which may or may not trigger a scheduling event. ...
      (Linux-Kernel)
    • Re: Incorrect CPU process accounting using CONFIG_HZ=100
      ... cpu resources, while at the same time reflecting an accurate view of cpu utilization? ... To properly account system v user time using the sched_clock we'd have to hook into arch dependant asm code to know when entering and exiting kernel context. ... That is far more invasive than the simple on/off runqueue timing we currently do for scheduling accounting. ...
      (Linux-Kernel)
    • Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature
      ... It's similar to running out of CPU bandwidth, ... >> Whether it meets the spirit of the standard is debatable. ... > deterministic scheduling order, and a deterministic scheduling ... When Con and Ingo started floating scheduler proposals, ...
      (Linux-Kernel)
    • Re: Analysis of sched_mc_power_savings
      ... completely idle packages to go to the available deepest P and C states. ... the cpu tickless idle time atleast on few CPU in an SMP machine. ... But the problem is we will not be able get longer idle time and goto ... But atleast we should not see any scheduling ...
      (Linux-Kernel)
    • Re: [PATCH 2 of 4] Introduce i386 fibril scheduling
      ... /common case/ - because the DB manages the cache itself. ... hardware is such that another CPU can pick it up in the next cycle. ... necessarily - it's a general scheduling decision. ... So can you take a look at Zach's fibril idea again? ...
      (Linux-Kernel)