Date: Fri, 14 Mar 2008 22:49:52 +0530 From: "Joseph Koshy" <joseph.koshy@gmail.com> To: "Jeff Roberson" <jroberson@chesapeake.net> Cc: freebsd-arch@freebsd.org Subject: Re: [PATCH] hwpmc(4) changes to use 'mp_maxid' instead of 'mp_ncpus'. Message-ID: <84dead720803141019j5b3d6cbfyf23583596ba97f88@mail.gmail.com> In-Reply-To: <20080313200839.S1091@desktop> References: <20080313180805.GA83406@dragon.NUXI.org> <200803131516.12284.jhb@freebsd.org> <84dead720803132232k15c3aad7pe59875f0c84e0c27@mail.gmail.com> <20080313200839.S1091@desktop>
next in thread | previous in thread | raw e-mail | index | archive | help
jr> In general we accept vendor patches that are not disruptive even in the jr> case that the general communit doesn't perceive the real value. It is jr> important for us to work with and encourage vendors. Well thats ok, but we need to keep the quality bar too and 'do the right thing'. jr> We're not asking you to support the feature. It looks like juniper jr> already has it tested and working. We just need someone to review the jr> patches and commit them. The patch offers userland a way to get the kernel to schedule threads on non-existent CPUS. So I'm curious to know how it was 'tested' in Juniper. As for support, I'm the one currently answering questions and fielding the bug reports about PmcTools. > The majority of the kernel already deals with sparse cpu mappings. That's > why we have CPU_ABSENT(). Please look at UMA and ULE for examples of code > that I have written which use this macro correctly. I'm sure there are > other places that do as well that I'm not familiar with. Yes, I suggested changes to kern_pmc.c that use CPU_ABSENT(). > The kernel has the various cpumasks available in sys/smp.h. Userland can > now use cpusets to find out what processors are available to it. In the > future we are going to replace simple cpumasks with the cpuset_t structure > from cpusets so on machines that support more than sizeof(register) * 8 > processors we will use arrays. Ok, will read up about cpusets. A manual page would help. > > - How will userland distinguish between absent CPUs those that > > could be temporarily administratively disabled? > > We don't presently make the distinction to the user. Ok, we can treat them both as 'missing'. HWPMC cannot deal with CPUs that come and go though. > The rest of the generic code in the kernel already supports this. The MD layers need to catch up then? > Juniper claims to have tested and is using this feature. Define 'tested'. > Furthermore, it will get us a tiny step closer to being able to support > pluggable cpus in a virtualized environment. Ok, but that isn't really relevant to HWPMC. Virtualized environments do not usually emulate PMCs. Thanks, Koshy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?84dead720803141019j5b3d6cbfyf23583596ba97f88>