2003-06-02 19:36:59

by Pete Zaitcev

[permalink] [raw]
Subject: sys_lookup_dcookie on s390

Martin,

Are you going to assign a number for lookup_dcookie? If yes, when?

-- Pete


2003-06-03 09:13:14

by Martin Schwidefsky

[permalink] [raw]
Subject: Re: sys_lookup_dcookie on s390


Hi Pete,

> Are you going to assign a number for lookup_dcookie? If yes, when?

You can use 110 for lookup_dcookie (reusing i386 specific iopl number that
have always been unused for s390). Never came around porting the oprofile
stuff to s390. Do you plan to do it ?

blue skies,
Martin


2003-06-03 16:18:01

by Pete Zaitcev

[permalink] [raw]
Subject: Re: sys_lookup_dcookie on s390

> From: "Martin Schwidefsky" <[email protected]>
> Date: Tue, 3 Jun 2003 11:22:32 +0200

> > Are you going to assign a number for lookup_dcookie? If yes, when?
>
> You can use 110 for lookup_dcookie (reusing i386 specific iopl number that
> have always been unused for s390). Never came around porting the oprofile
> stuff to s390. Do you plan to do it ?

I am going to use it with timer profiling at first.
It is essentially zero effort port, just add the syscall
and config.in entry.

Still, do you have a suggestion for any other interrupt?
For instance, on i386 it can use NMI. It is my understanding
(perhaps incorrect), that using other interrupt can
a) increase precision, if HZ is low, but other interrupt can
fire more often, b) reduce overhead. Also, sometimes you can
do tricks, if hardware allows it. On sparc, for instance,
you can redefine __local_cli() in such a way that all interrupts
would be closed except the profiling interrupt. Then, the
profiler gathers data about people sitting on spinlocks, etc.
This is what I am looking for, but I'm not sufficiently versed
in the architecture for decide if we have a suitable interrupt
source.

-- Pete