Date: Thu, 23 Apr 2009 09:59:39 -0400 From: John Baldwin <jhb@freebsd.org> To: Robert Watson <rwatson@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r191405 - in head/sys: amd64/amd64 i386/i386 Message-ID: <200904230959.39423.jhb@freebsd.org> In-Reply-To: <alpine.BSF.2.00.0904231253140.54334@fledge.watson.org> References: <200904222140.n3MLebn3068260@svn.freebsd.org> <alpine.BSF.2.00.0904231253140.54334@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 23 April 2009 7:55:53 am Robert Watson wrote: > On Wed, 22 Apr 2009, John Baldwin wrote: > > > Adjust the way we number CPUs on x86 so that we attempt to "group" all > > logical CPUs in a package. We do this by numbering the non-boot CPUs > > by starting with the first CPU whose APIC ID is after the boot CPU and > > wrapping back around to APIC ID 0 if needed rather than always starting > > at APIC ID 0. While here, adjust the cpu_mp_announce() routine to list > > CPUs based on the mapping established by assign_cpu_ids() rather than > > making assumptions about the algorithm assign_cpu_ids() uses. > > Something we'd like to be able to do in the fairly near future is assign work > from one thread/core to another thread/core that is cache-wise "close" to the > current one. For example, if we take a cacheline miss on an mbuf head and the > first line of a packet's data on one CPU, and want to hand it off to another > CPU for further processing, trying to send it somewhere where it's already > quite close, cache-wise, might well be beneficial. Likewise, sending it to > another thread or core that is cache-wise close on the lock protecting the > queue used to pass it between CPUs, would also be nice. > > Do you have any ideas about ways to usefully represent and manage concepts > like "pick a close CPU" or "the set of CPUs that are close"? For example, if > I have available a flow identifier, hashing to one of a set of available CPUs > is easy, but what would you suggest as an efficient representation to hash > from a set of close available CPUs rather than the entire pool? In theory, this is the job of the topology stuff that is available for the scheduler to use to make similar decisions. The purpose of this patch is to make it easier for system administrators who are using /usr/bin/cpuset to tie tasks to specific cores at more of a macro level by providing a more consistent layout of CPU IDs. Presumably this would matter less if cpuset was topology-aware such that you could specify a set by <package,core,thread> tuples rather than CPU IDs to identify CPUs. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200904230959.39423.jhb>