Re: SCHED_ULE and nice still ignored

From: Harald Schmalzbauer (h_at_schmalzbauer.de)
Date: 01/31/04

  • Next message: Peter Jeremy: "Re: Call for testers: New PID allocator patch for -CURRENT"
    To: Steve Kargl <sgk@troutmask.apl.washington.edu>
    Date: Sat, 31 Jan 2004 22:31:55 +0100
    
    
    

    On Saturday 31 January 2004 22:24, Steve Kargl wrote:
    > On Sat, Jan 31, 2004 at 09:46:29PM +0100, Harald Schmalzbauer wrote:
    > Content-Description: signed data
    >
    > > like I reported some weeks ago, SCHED_ULE seems to ignore nice.
    > > Since it's now the default I gave it another try and did the following
    > > simple test:
    > >
    > > SCHED_ULE:
    > > seti in background (doesn't matter if nice=20 or 15)
    > > /usr/ports/sysutils/cpdup
    > > make install takes Minutes
    > >
    > > Without seti it takes some seconds
    > >
    > > SCHED_4BSD:
    > > seti in background (doesn't matter if nice=20 or 15)
    > > /usr/ports/sysutils/cpdup
    > > make install finishes in seconds. No difference with or without seti
    > >
    > >
    > > Please let us know when nice gets respected by SCHED_ULE so I can really
    > > use it as default scheduler.
    >
    > Seems to work for me. You need to describe your problem better.
    >
    > last pid: 70890; load averages: 2.49, 1.86, 1.54 up 1+17:55:17
    > 13:23:16 64 processes: 5 running, 59 sleeping
    > CPU states: 16.8% user, 4.6% nice, 77.7% system, 1.0% interrupt, 0.0%
    > idle Mem: 120M Active, 176M Inact, 58M Wired, 18M Cache, 48M Buf, 1072K
    > Free Swap: 356M Total, 356M Free

    Ok, perhaps nice is working in some way, but as I described earlier far away
    from what it should do.
    If I start a process with nice 15 (like seti) it shouldn't slow down my
    machine by exponetial factors.
    It should take cycles which are almost unused and not block regular processes
    (like make)

    If you want to know exact values, I can take a clock and measure the exact
    divverence, but I think this is not needed at all since the differenc isn't
    marignal, its minutes vs. seconds.

    -Harry

    >
    > PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
    > 592 kargl 76 0 35248K 34284K RUN 600:36 1.56% 1.56% XFree86
    > 70093 kargl 8 20 1708K 1000K wait 0:00 1.56% 1.56% sh
    > 70889 kargl 139 20 4152K 3148K RUN 0:00 1.56% 1.56% cc1
    > 70887 kargl 8 20 328K 220K wait 0:00 1.56% 1.56% gcc
    > 70886 kargl 8 20 1708K 1000K wait 0:00 1.56% 1.56% sh
    > 822 kargl 76 0 5000K 3276K select 2:02 0.78% 0.78% xterm
    > 70792 root 8 0 1336K 1216K wait 0:00 0.78% 0.78% make
    > 70888 root 8 0 1660K 944K wait 0:00 0.78% 0.78% sh
    > 70890 root 139 0 1568K 632K RUN 0:00 0.78% 0.78% gzip
    > 606 kargl 76 0 5068K 3340K RUN 0:01 0.00% 0.00% xterm
    > 70765 kargl 76 0 2312K 1364K RUN 0:00 0.00% 0.00% top

    
    


    • application/pgp-signature attachment: signature

  • Next message: Peter Jeremy: "Re: Call for testers: New PID allocator patch for -CURRENT"

    Relevant Pages

    • Re: SCHED_ULE and nice still ignored
      ... > make install finishes in seconds. ... No difference with or without seti ... PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND ...
      (freebsd-current)
    • Re: Cant open hosts file on xp!
      ... Yes still a SETI phan... ... years processing WUs ... As for the upgrade from one OS to WinXP, it is always best to do a clean install with *any* ...
      (alt.computer.security)
    • Re: Seti and XP Pro
      ... I have had no problem running Seti with XP Pro for the last 6 weeks since ... run with other similar shared computing programs such as United Devices UD ... > new install of XP pro on a new PC and the same programmes installed as on ...
      (microsoft.public.windowsxp.help_and_support)
    • SCHED_ULE and nice still ignored
      ... seti in background (doesn't matter if nice=20 or 15) ... Without seti it takes some seconds ... make install finishes in seconds. ... it as default scheduler. ...
      (freebsd-current)