Re: ULE vs. 4BSD in RELENG_7

On 10/24/07, Josh Carroll <josh.carroll@xxxxxxxxx> wrote:

Yes, that's the proper default. You could try setting steal_thresh to 1.
I
noticed a problem with building ports on an 8 core Xeon system while 8
distributed.net crunchers were running. The port build would proceed
incredibly slowly, steal_thresh=1 helped a little bit. It might not make
up
the 5% gap you're seeing though. During early ULE2/3 testing the other
variables Jeff recommended trying were sched.pick_pri (which I never saw
effect from), sched_tryself and sched.balance. They're all bools IIRC.
Since
this workload is a bit different from any of mine it would be worthwhile
to
try those variables.

Thanks for the information. Setting sched_tryself to 0 improved things
slightly. sched.balance didn't seem to help. I'm trying to
increase/decrease the balance_interval to see if that helps.



It's worth noting that there are kernel threads competing to run as well.
For example ithread and taskqueue threads. How does ULE differentiate and
schedule I/O bound threads?
_______________________________________________
freebsd-performance@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "freebsd-performance-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Blocking/responding to port scans
    ... >>Also worth noting that if you have even 1 service listing i.e. an open ... >>port then it's irrelevant to this the argument on 'invisibility' whether ...
    (comp.os.linux.security)
  • Re: Blocking/responding to port scans
    ... > Also worth noting that if you have even 1 service listing i.e. an open ... > port then it's irrelevant to this the argument on 'invisibility' whether ... > you DROPor REJECT the packets as a the person performing the port ... a fairly boring scanner - and potentially a mistaken basically legitimate ...
    (comp.os.linux.security)
  • Re: Blocking/responding to port scans
    ... > Also worth noting that if you have even 1 service listing i.e. an open ... > port then it's irrelevant to this the argument on 'invisibility' whether ...
    (comp.os.linux.security)
  • Re: Blocking/responding to port scans
    ... > host unreachable, port unreachable, or what have you. ... It could either be that the host is offline, ... > hacker encounters that, then they could be more interested. ... Also worth noting that if you have even 1 service listing i.e. an open ...
    (comp.os.linux.security)