mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Paul Jackson <pj@sgi.com>
To: Jim Nance <jlnance@sdf.lonestar.org>
Cc: davidsen@tmr.com, davej@redhat.com, willy@w.ods.org,
	akpm@osdl.org, jfbeam@bluetronic.net,
	nico-kernel@schottelius.org, linux-kernel@vger.kernel.org
Subject: Re: /proc/cpuinfo format - arch dependent!
Date: Tue, 10 May 2005 00:13:27 -0700	[thread overview]
Message-ID: <20050510001327.5197dd21.pj@sgi.com> (raw)
In-Reply-To: <20050510022301.GA13763@SDF.LONESTAR.ORG>

Jim wrote:
> I see two problems with encouraging applications to get involved
> with processor selection.

I suspect you are confusing "application" with "not kernel".

There are basically three layers of software on big systems:

 1) kernel
 2) administration (system services, libraries and utilities)
 3) application

Something like a batch manager is an example in layer (2) that needs
extensive knowledge of a systems hardware, and extensive ability to
manage exactly what runs and allocates where.

Large systems very much expect to manage what threads run where. These
API's are already present - check out sched_setaffinity, mbind,
set_mempolicy, and cpusets.  The details of what hardware is where,
including memory, processor and interconnect, are also there as well, in
various /proc and /sys files.

No - we don't expect the application to know all this.  But we absolutely
require that various admin level programs know this stuff in intimate
detail, and enable the administration of large systems in a variety of
ways.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401

  parent reply	other threads:[~2005-05-10  7:14 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-19 12:15 Nico Schottelius
2005-04-19 13:24 ` Lennart Sorensen
2005-04-19 19:17   ` Lee Revell
2005-04-19 20:00     ` Nico Schottelius
2005-04-19 20:02       ` David S. Miller
2005-04-19 20:12       ` Lennart Sorensen
2005-04-19 20:42       ` Lee Revell
2005-04-19 20:54         ` Nico Schottelius
2005-04-19 21:12           ` Grzegorz Kulewski
2005-04-20 20:31   ` Ralf Baechle
2005-05-07  3:37 ` Ricky Beam
2005-05-07  4:01   ` Stefan Smietanowski
2005-05-07  7:55     ` Ricky Beam
2005-05-07 17:51       ` Stefan Smietanowski
2005-05-07 18:05         ` Ricky Beam
2005-05-07 18:46           ` Dr. David Alan Gilbert
2005-05-07  4:14   ` Andrew Morton
2005-05-07  7:58     ` Willy Tarreau
2005-05-07 16:53       ` Dave Jones
2005-05-07 17:05         ` Willy Tarreau
2005-05-07 17:20           ` Dave Jones
2005-05-07 17:18             ` Willy Tarreau
2005-05-08  1:25             ` Jim Nance
2005-05-08 16:11               ` John Kacur
2005-05-09 18:14               ` Bill Davidsen
2005-05-09 20:09                 ` Chris Friesen
2005-05-09 20:26                   ` Lennart Sorensen
2005-05-09 21:25                     ` Brian O'Mahoney
2005-05-10 16:21                   ` Bill Davidsen
2005-05-10 16:34                     ` Chris Friesen
2005-05-10  2:23                 ` Jim Nance
2005-05-10  4:12                   ` Willy Tarreau
2005-05-10  7:13                   ` Paul Jackson [this message]
2005-05-10 16:34                   ` Bill Davidsen
2005-05-07 17:54       ` Stefan Smietanowski
2005-05-07 18:05         ` Willy Tarreau
2005-05-09 18:03     ` Bill Davidsen
2005-05-10  7:21     ` Paul Jackson
2005-05-10 14:38       ` Lennart Sorensen
2005-05-10 16:37         ` Bill Davidsen
2005-05-09 18:00   ` Bill Davidsen
2005-05-09 19:58     ` Lennart Sorensen
2005-05-10 16:49       ` Bill Davidsen
     [not found] <3UZS7-5ue-17@gated-at.bofh.it>
     [not found] ` <41ouh-4QE-1@gated-at.bofh.it>
     [not found]   ` <41oXl-5hl-7@gated-at.bofh.it>
     [not found]     ` <41sxX-8cN-11@gated-at.bofh.it>
     [not found]       ` <41BL4-7l7-15@gated-at.bofh.it>
2005-05-07 23:33         ` Bodo Eggert <harvested.in.lkml@posting.7eggert.dyndns.org>
2005-05-08 13:24           ` Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050510001327.5197dd21.pj@sgi.com \
    --to=pj@sgi.com \
    --cc=akpm@osdl.org \
    --cc=davej@redhat.com \
    --cc=davidsen@tmr.com \
    --cc=jfbeam@bluetronic.net \
    --cc=jlnance@sdf.lonestar.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nico-kernel@schottelius.org \
    --cc=willy@w.ods.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®