Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 04 Apr 2002 17:55:53 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Stephen J Bevan <stephen@etunnels.com>
Cc:        John Regehr <regehr@cs.utah.edu>, freebsd-hackers@FreeBSD.ORG
Subject:   Re: Linuxthreads on Linux vs FreeBSD performance question
Message-ID:  <3CAD0429.1A196F48@mindspring.com>
References:  <Pine.LNX.4.21.0204031311270.15454-100000@famine.cs.utah.edu> <3CAC036C.71DB41BB@mindspring.com> <15532.35908.341722.136026@apathy.etunnels.com> <3CACE84F.D54C9248@mindspring.com> <15532.60584.310576.443702@apathy.etunnels.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Stephen J Bevan wrote:
>   This is the same way that the scheduling CPU and process group
>   affinity crap that Linux puts up with just falls out of the
>   code, as well, when you go to per CPU run queues
> 
> Since the thread on freebsd-arch didn't appear to have anything
> specifically to do with Linux 2.4.17 (it was about adding VOPs in
> FreeBSD) I assumed you weren't aware that the scheduler had changed
> over the last few months otherwise you wouldn't have mentioned the
> issue.  Again, my mistake.

I should have been clearer.  When it comes to multiple CPUs
in the same machine, what you are really trying to achieve
is group negaffinity for the same CPU, in order to maximize
concurrency.

The intra-CPU affinity in Linux is what I am saying is bad, in
that statement.  The inter-cpu negaffinity isn't that hot, either.

This is seperate form the issue of the act of migration of a
proceess from one CPU sheduler queue to another: the negaffinity
is about the decision of *when* to migrate, while the per CPU
scheduling queues is about the decision of *how* to migrate.

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CAD0429.1A196F48>