Re: /proc/cpuinfo format - arch dependent!

[Willy Tarreau <willy@w.ods.org>]

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/