Date: Sat, 7 May 2005 19:18:51 +0200
From: Willy Tarreau <willy@w.ods.org>
To: Dave Jones <davej@redhat.com>, Andrew Morton <akpm@osdl.org>,
       Ricky Beam <jfbeam@bluetronic.net>, nico-kernel@schottelius.org,
       linux-kernel@vger.kernel.org
Subject: Re: /proc/cpuinfo format - arch dependent!
Message-ID: <20050507171850.GA19380@alpha.home.local>
References: <20050419121530.GB23282@schottelius.org> <Pine.GSO.4.33.0505062324550.1894-100000@sweetums.bluetronic.net> <20050506211455.3d2b3f29.akpm@osdl.org> <20050507075828.GF777@alpha.home.local> <20050507165357.GA19601@redhat.com> <20050507170555.GA19329@alpha.home.local> <20050507172005.GB26088@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050507172005.GB26088@redhat.com>
User-Agent: Mutt/1.4i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1777
Lines: 37

On Sat, May 07, 2005 at 01:20:05PM -0400, Dave Jones wrote:
> On Sat, May 07, 2005 at 07:05:56PM +0200, Willy Tarreau wrote:
> 
>  > Well, that's exactly for this that I formulated the proposal. A
>  > CPU-intensive application which benefits from the cache would better
>  > choose to run on HT pairs. A network-hungry application will prefer
>  > running on only one sibling of each HT pair, and probably one process
>  > per core, particularly when each core receives one NIC's interrupt.
>  > A memory bandwidth intensive application will choose to run on a
>  > single NUMA node, etc... So either the application can choose this
>  > itself from its understanding of the CPU layout, or it can ask the
>  > system "hey, I'd like this type of workload, how many process should
>  > I start, and where should I bind them ?".
> 
> I think generalising this and having a method to do this in the kernel
> is a much better idea than each application parsing this themselves.
> Things are only getting more and more complex as time goes on,
> and I don't trust application developers to get it right.
> 
> Centralising this in the kernel (or maybe even glibc) means we can get
> it right, and have every application benefit. If we get it wrong, we
> fix it, and all the applications are fixed without needing fixing/recompiling.

Agreed.

Even more, support for newer layouts would only require a kernel upgrade
and not an application update. And porting applications to other
architectures would be more transparent.

Regards,
Willy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/