Re: [OT] Process on which processor

2003-03-18 Thread Albert Cahalan
nate writes:

 there was a SMP patch for procps a couple years ago,
 which also added SMP support to top.

That's very buggy and obsolete. Something like it
went into Red Hat; better code is in debian-unstable.

 I remember the 'ps' from it would show which
 processor a process was on. So look into that.
 perhaps a recompile of procps will give SMP
 support. I have a redhat 7.3 system here which
 has a SMP-aware top but ps doesn't seem to show
 anything CPU related.

 looks like the more recent versions of procps do
 not sport a SMP aware ps, I just recompiled the
 latest from sourceforge and do not see anything
 SMP except in top.

You could ask ps to display this mostly-useless info.
It shows up under columns named ENG, CPU, PSR, or P.
Some commands that will get this data:

ps -F
ps -P
PS_PERSONALITY=sgi ps -l
ps -o pid,sgi_p,psr,comm



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Code forks, RH Debian (was Re: [OT] Process on which processor)

2003-01-14 Thread Ron Johnson
On Mon, 2003-01-13 at 17:50, Colin Watson wrote:
 On Mon, Jan 13, 2003 at 12:32:43PM -0800, nate wrote:
[snip]
 Be careful of applying the words older and newer to procps. There
 are two forks of its codebase, and I don't think their version numbers
 track each other.
 
 It wouldn't be the first time that Red Hat and Debian have ended up for
 various historical reasons on two different branches of a fork: man and
 man-db come to mind, but at least there the packages have different
 names.

Ok, I'll bite:
Why do Debian and RH track different branches of extremely common
packages like top and man?

-- 
++
| Ron Johnson, Jr. mailto:[EMAIL PROTECTED]  |
| Jefferson, LA  USA   http://members.cox.net/ron.l.johnson  |
||
| Basically, I got on the plane with a bomb. Basically, I   |
|  tried to ignite it. Basically, yeah, I intended to damage |
|  the plane.   |
|RICHARD REID, who tried to blow up American Airlines|
|  Flight 63 |
++


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]




Re: Code forks, RH Debian (was Re: [OT] Process on which processor)

2003-01-14 Thread Colin Watson
On Tue, Jan 14, 2003 at 05:56:19PM -0600, Ron Johnson wrote:
 On Mon, 2003-01-13 at 17:50, Colin Watson wrote:
  Be careful of applying the words older and newer to procps. There
  are two forks of its codebase, and I don't think their version numbers
  track each other.
  
  It wouldn't be the first time that Red Hat and Debian have ended up for
  various historical reasons on two different branches of a fork: man and
  man-db come to mind, but at least there the packages have different
  names.
 
 Ok, I'll bite:
 Why do Debian and RH track different branches of extremely common
 packages like top and man?

Historical reasons, as I said. :) Six years ago it wasn't always obvious
that the other branches existed, and even if it was people just picked
whatever implementation looked best when they were putting together a
distribution. There wasn't necessarily any overriding reason back then
why Debian and Red Hat should have picked the same implementation of
everything, or even necessarily been particularly aware of what the
other was doing. Since then you often find that the branches have
diverged too far apart to be simply merged, and both have had different
features added which people want; switching branches would lead to
people being surprised by features disappearing.

It's unfortunate, but there you go. Competition is occasionally healthy.
Since it's all free software, the best thing to do is to try to merge as
much as possible.

-- 
Colin Watson  [[EMAIL PROTECTED]]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]




Re: [OT] Process on which processor

2003-01-13 Thread nate
deFreese, Barry said:
 Hello,

 OK, I know that there is no processor affinity under Linux but is there a
 way to tell which processes are running on which processor on an SMP
 kernel?


there was a SMP patch for procps a couple years ago, which also added
SMP support to top. I remember the 'ps' from it would show which processor
a process was on. So look into that. perhaps a recompile of procps will
give SMP support. I have a redhat 7.3 system here which has a SMP-aware
top but ps doesn't seem to show anything CPU related.

looks like the more recent versions of procps do not sport a SMP aware ps,
I just recompiled the latest from sourceforge and do not see anything
SMP except in top.

so you may need to get a much older version of procps and install it with
the patch(this may be the right patch):
http://www.cs.inf.ethz.ch/~rauch/smp1/procps-1.2.9.smp.patch2

not sure if that version of procps is compadible with newer 2.4.x or 2.5.x
kernels.

nate




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]




Re: [OT] Process on which processor

2003-01-13 Thread Colin Watson
On Mon, Jan 13, 2003 at 12:32:43PM -0800, nate wrote:
 there was a SMP patch for procps a couple years ago, which also added
 SMP support to top. I remember the 'ps' from it would show which processor
 a process was on. So look into that. perhaps a recompile of procps will
 give SMP support. I have a redhat 7.3 system here which has a SMP-aware
 top but ps doesn't seem to show anything CPU related.
 
 looks like the more recent versions of procps do not sport a SMP aware ps,
 I just recompiled the latest from sourceforge and do not see anything
 SMP except in top.
 
 so you may need to get a much older version of procps and install it with
 the patch(this may be the right patch):

[...]

Be careful of applying the words older and newer to procps. There
are two forks of its codebase, and I don't think their version numbers
track each other.

It wouldn't be the first time that Red Hat and Debian have ended up for
various historical reasons on two different branches of a fork: man and
man-db come to mind, but at least there the packages have different
names.

-- 
Colin Watson  [[EMAIL PROTECTED]]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]