From owner-freebsd-arch@FreeBSD.ORG Fri Mar 14 17:19:55 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3DAD1065671 for ; Fri, 14 Mar 2008 17:19:54 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id 92E1C8FC29 for ; Fri, 14 Mar 2008 17:19:54 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so3476846fgg.35 for ; Fri, 14 Mar 2008 10:19:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=1GQB49w7QBBldtGyg3khojJmKlhpnM00zt0duzLXKR0=; b=suDXvdqi75c33kTMr5S3MQdNBMlkDFKucy0rkgzbZ0IOEraUmMU5yLtLejgt3DPXx446az6G7GJhHWbJWqrpeAsSobFgRFpUJWaOQM8yfYNQe5oOaXD0Ei4wqSFaW4iVuoJceFw1cBjSLzdZcumahxxxpmiZQEf2PApzl1NW3hk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=D3VHdqMcdFxbdVErspSqNmmhz2Iy8WxxQ4fdnSU0qxlss5ldx0tjFvLS+KlQxgjca75sm9BPX5IUf6hldmeGXBSqIU8dtv4T48jpsWo0XHdmBCDyn//9BDwqDVIW9KeYyn+fQXK6EwZM/YTyrnTSul++415fpgpQ1OXRGd9RguE= Received: by 10.86.36.11 with SMTP id j11mr2740740fgj.5.1205515192945; Fri, 14 Mar 2008 10:19:52 -0700 (PDT) Received: by 10.86.99.18 with HTTP; Fri, 14 Mar 2008 10:19:52 -0700 (PDT) Message-ID: <84dead720803141019j5b3d6cbfyf23583596ba97f88@mail.gmail.com> Date: Fri, 14 Mar 2008 22:49:52 +0530 From: "Joseph Koshy" To: "Jeff Roberson" In-Reply-To: <20080313200839.S1091@desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080313180805.GA83406@dragon.NUXI.org> <200803131516.12284.jhb@freebsd.org> <84dead720803132232k15c3aad7pe59875f0c84e0c27@mail.gmail.com> <20080313200839.S1091@desktop> Cc: freebsd-arch@freebsd.org Subject: Re: [PATCH] hwpmc(4) changes to use 'mp_maxid' instead of 'mp_ncpus'. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2008 17:19:55 -0000 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