[Linux-ia64] Re: prctl patch for fpu faults

[Linux-ia64] Re: prctl patch for fpu faults

[David Mosberger]

>>>>> On Mon, 8 Oct 2001 14:57:00 -0700, Jesse Barnes <jbarnes@sgi.com> said:

  Jesse> I think you mentioned awhile ago that a patch like this might be
  Jesse> welcome.  Well, here it is.  It's diff'd against 2.4.10 with the ia64
  Jesse> patch.  Please let me know if you find problems with it.

The patch looks mostly good to me.  However, why did you get rid of
the rate limiting code?  I think we still want that.

	--david

[Linux-ia64] Re: prctl patch for fpu faults

[Jesse Barnes]

The rate limiting stuff really limits the usefulness of the code I think.  
If you want to get notified of faults, you probably want all of them, and
you want to know the ip for each occurence.  If you just get some, it
doesn't help you debug your code.  Maybe there could be a NOTIFY option or
something that would get printed only once if the app generated a fault?

Thanks,
Jesse

On Mon, 8 Oct 2001, David Mosberger wrote:

> >>>>> On Mon, 8 Oct 2001 14:57:00 -0700, Jesse Barnes <jbarnes@sgi.com> said:
> 
>   Jesse> I think you mentioned awhile ago that a patch like this might be
>   Jesse> welcome.  Well, here it is.  It's diff'd against 2.4.10 with the ia64
>   Jesse> patch.  Please let me know if you find problems with it.
> 
> The patch looks mostly good to me.  However, why did you get rid of
> the rate limiting code?  I think we still want that.
> 
> 	--david
> 

[Linux-ia64] Re: prctl patch for fpu faults

[David Mosberger]

>>>>> On Mon, 8 Oct 2001 16:46:41 -0700, Jesse Barnes <jbarnes@sgi.com> said:

  Jesse> The rate limiting stuff really limits the usefulness of the
  Jesse> code I think.  If you want to get notified of faults, you
  Jesse> probably want all of them, and you want to know the ip for
  Jesse> each occurence.  If you just get some, it doesn't help you
  Jesse> debug your code.  Maybe there could be a NOTIFY option or
  Jesse> something that would get printed only once if the app
  Jesse> generated a fault?

I feel pretty strongly that we should handle fpswa faults the same way
as unaligned faults.  Given that we rate limit the unaligned faults,
I'd prefer to rate limit fpswa as well.  Of course, if you think you'd
want to debug more than 5 faults at a time, you could change the
tuning parameters (allowing for longer bursts, while keeping the
logging rate the same).

	--david

[Linux-ia64] Re: prctl patch for fpu faults

[Jesse Barnes]

Sure, ok.  Would you like me to submit a new patch that includes the rate
limiting stuff as the default or do you just wanna hack that stuff back
in?

Thanks,
Jesse

On Mon, 8 Oct 2001, David Mosberger wrote:
> 
> I feel pretty strongly that we should handle fpswa faults the same way
> as unaligned faults.  Given that we rate limit the unaligned faults,
> I'd prefer to rate limit fpswa as well.  Of course, if you think you'd
> want to debug more than 5 faults at a time, you could change the
> tuning parameters (allowing for longer bursts, while keeping the
> logging rate the same).
> 
> 	--david
> 

[Linux-ia64] Re: prctl patch for fpu faults

[Jesse Barnes]

Err... maybe an ALLPRINT option would be nice instead?  Our apps guys were
requesting that they be given all the fault messages and ip's.  The
current behavior could be the default though.

Jesse

On Mon, 8 Oct 2001, Jesse Barnes wrote:

> Sure, ok.  Would you like me to submit a new patch that includes the rate
> limiting stuff as the default or do you just wanna hack that stuff back
> in?
> 
> Thanks,
> Jesse
> 
> On Mon, 8 Oct 2001, David Mosberger wrote:
> > 
> > I feel pretty strongly that we should handle fpswa faults the same way
> > as unaligned faults.  Given that we rate limit the unaligned faults,
> > I'd prefer to rate limit fpswa as well.  Of course, if you think you'd
> > want to debug more than 5 faults at a time, you could change the
> > tuning parameters (allowing for longer bursts, while keeping the
> > logging rate the same).
> > 
> > 	--david
> > 
> 
> 

Re: [Linux-ia64] Re: prctl patch for fpu faults

[Jesse Barnes]

Here's another one.  Please let me know if it's ok.

Thanks,
Jesse

diff -Naur linux-2.4.10-ia64/arch/ia64/kernel/traps.c linux-2.4.10-ia64-fpswa/arch/ia64/kernel/traps.c
--- linux-2.4.10-ia64/arch/ia64/kernel/traps.c	Mon Oct  8 16:55:54 2001
+++ linux-2.4.10-ia64-fpswa/arch/ia64/kernel/traps.c	Mon Oct  8 17:04:03 2001
@@ -311,7 +311,8 @@
 
 	if (jiffies - last_time > 5*HZ)
 		fpu_swa_count = 0;
-	if (++fpu_swa_count < 5) {
+	if ((current->thread & IA64_THREAD_FPSWA_ALLPRINT) ||
+	    (++fpu_swa_count < 5 && !(current->thread.flags & IA64_THREAD_FPSWA_NOPRINT)) {
 		last_time = jiffies;
 		printk(KERN_WARNING "%s(%d): floating-point assist fault at ip %016lx\n",
 		       current->comm, current->pid, regs->cr_iip + ia64_psr(regs)->ri);
@@ -512,7 +513,7 @@
 	      case 32: /* fp fault */
 	      case 33: /* fp trap */
 		result = handle_fpu_swa((vector = 32) ? 1 : 0, regs, isr);
-		if (result < 0) {
+		if (result < 0 || (current->thread.flags & IA64_THREAD_FPSWA_SIGFPE)) {
 			siginfo.si_signo = SIGFPE;
 			siginfo.si_errno = 0;
 			siginfo.si_code = FPE_FLTINV;
diff -Naur linux-2.4.10-ia64/include/asm-ia64/processor.h linux-2.4.10-ia64-fpswa/include/asm-ia64/processor.h
--- linux-2.4.10-ia64/include/asm-ia64/processor.h	Mon Oct  8 16:55:55 2001
+++ linux-2.4.10-ia64-fpswa/include/asm-ia64/processor.h	Mon Oct  8 17:05:46 2001
@@ -168,8 +168,13 @@
 #define IA64_THREAD_UAC_NOPRINT	(__IA64_UL(1) << 3)	/* don't log unaligned accesses */
 #define IA64_THREAD_UAC_SIGBUS	(__IA64_UL(1) << 4)	/* generate SIGBUS on unaligned acc. */
 #define IA64_THREAD_KRBS_SYNCED	(__IA64_UL(1) << 5)	/* krbs synced with process vm? */
+#define IA64_THREAD_FPSWA_NOPRINT (__IA64_UL(1) << 6)   /* don't log any fpswa faults */
+#define IA64_THREAD_FPSWA_ALLPRINT (__IA64_UL(1) << 7)  /* log all fpswa faults */
+#define IA64_THREAD_FPSWA_SIGFPE  (__IA64_UL(1) << 8)   /* send a SIGFPE for fpswa faults */
 #define IA64_KERNEL_DEATH	(__IA64_UL(1) << 63)	/* see die_if_kernel()... */
 
+#define IA64_THREAD_FPSWA_SHIFT 6
+#define IA64_THREAD_FPSWA_MASK  (IA64_THREAD_FPSWA_NOPRINT | IA64_THREAD_FPSWA_ALLPRINT | IA64_THREAD_FPSWA_SIGFPE)
 #define IA64_THREAD_UAC_SHIFT	3
 #define IA64_THREAD_UAC_MASK	(IA64_THREAD_UAC_NOPRINT | IA64_THREAD_UAC_SIGBUS)
 
@@ -322,6 +327,18 @@
 #define GET_UNALIGN_CTL(task,addr)								\
 ({												\
 	put_user(((task)->thread.flags & IA64_THREAD_UAC_MASK) >> IA64_THREAD_UAC_SHIFT,	\
+		 (int *) (addr));								\
+})
+
+#define SET_FPSWA_CTL(task,value)								\
+({												\
+	(task)->thread.flags = (((task)->thread.flags & ~IA64_THREAD_FPSWA_MASK)		\
+				| (((value) << IA64_THREAD_FPSWA_SHIFT) & IA64_THREAD_FPSWA_MASK));	\
+	0;											\
+})
+#define GET_FPSWA_CTL(task,addr)								\
+({												\
+	put_user(((task)->thread.flags & IA64_THREAD_FPSWA_MASK) >> IA64_THREAD_FPSWA_SHIFT,	\
 		 (int *) (addr));								\
 })
 
diff -Naur linux-2.4.10-ia64/include/linux/prctl.h linux-2.4.10-ia64-fpswa/include/linux/prctl.h
--- linux-2.4.10-ia64/include/linux/prctl.h	Thu Jul 19 20:39:57 2001
+++ linux-2.4.10-ia64-fpswa/include/linux/prctl.h	Mon Oct  8 16:56:39 2001
@@ -20,4 +20,8 @@
 #define PR_GET_KEEPCAPS   7
 #define PR_SET_KEEPCAPS   8
 
+/* controls the printing of fpswa fault warnings */
+#define PR_GET_FPSWA  9
+#define PR_SET_FPSWA 10
+
 #endif /* _LINUX_PRCTL_H */
diff -Naur linux-2.4.10-ia64/kernel/sys.c linux-2.4.10-ia64-fpswa/kernel/sys.c
--- linux-2.4.10-ia64/kernel/sys.c	Tue Sep 18 14:10:43 2001
+++ linux-2.4.10-ia64-fpswa/kernel/sys.c	Mon Oct  8 16:56:39 2001
@@ -1245,6 +1245,22 @@
 #endif
 			break;
 
+	        case PR_SET_FPSWA:
+#ifdef SET_FPSWA_CTL
+			error = SET_FPSWA_CTL(current, arg2);
+#else
+			error = -EINVAL;
+#endif
+			break;
+
+	        case PR_GET_FPSWA:
+#ifdef GET_FPSWA_CTL
+			error = GET_FPSWA_CTL(current, arg2);
+#else
+			error = -EINVAL;
+#endif
+			break;
+
 		case PR_GET_KEEPCAPS:
 			if (current->keep_capabilities)
 				error = 1;

Re: [Linux-ia64] Re: prctl patch for fpu faults

[Jesse Barnes]

What if I were to get rid of the rate limited logging for both the
unaligned and fpswa handlers?  Then there could just be a NOPRINT option
and a signal option for each; the default behavior would be to log all
messages.  If you'd rather not get rid of it, then I'll just send a patch
to enable NOPRINT for fpswa (similar to what the unaligned handler does
now) and a signal option.

Does anyone else have an opinion on the rate limited logging for the
unaligned and fpswa handlers?  Some people have told me that they don't
think it's useful for admins or users to have some of the messages but not
all of them.

Thanks,
Jesse

On Tue, 9 Oct 2001, David Mosberger wrote:

> >>>>> On Tue, 9 Oct 2001 10:38:57 -0700, Jesse Barnes <jbarnes@sgi.com> said:
> 
>   Jesse> Wouldn't that mean you could only do one at a time,
>   Jesse> i.e. you'd be stuck with the rate limiting code even if you
>   Jesse> just wanted a signal, since there'd be no way to say NOPRINT
>   Jesse> | SIGFPE?  I'm really just trying to fill the needs of our
>   Jesse> application programmers, who say they want to get all the
>   Jesse> messages and/or get a signal.
> 
> No, I don't think so:
> 
> 	DEFAULT:	log message (with rate limit)
> 	NOPRINT:	be quiet about fixups (not rate limited)
> 	SIGNAL:		send signal (not rate limited)
> 	PRINTALL:	log message (not rate limited)
> 
> In other words, the rate-limiting only applies for the DEFAULT setting.
> 
> 	--david
> 

Re: [Linux-ia64] Re: prctl patch for fpu faults

[Jack Steiner]

> 
> What if I were to get rid of the rate limited logging for both the
> unaligned and fpswa handlers?  Then there could just be a NOPRINT option
> and a signal option for each; the default behavior would be to log all
> messages.  If you'd rather not get rid of it, then I'll just send a patch
> to enable NOPRINT for fpswa (similar to what the unaligned handler does
> now) and a signal option.

IMHO, the default for FPSWA fault (& probably unaligned access) should be OFF.
Lots of apps cause FP faults. AIM7, for example, causes faults at a fairly high
rate. I doubt that any server site would like to see the log polluted with 
these errors - especially since there is no way to identify the offending app.

There should be a way a site can change the default logging behavior & have it
apply to ALL tasks.. 


Remember that FPSWA is invoked for numerous reasons that are NOT necessarily 
errors in the application. (AIM7 generates FPSWA faults when it divides a
very small number by 2.0). Intel doesnt even specify all the conditions that cause
FPSWA to be invoked.

As far as rate limited vs full logging, I like rate limited. Otherwise, you can
flood the system with messages. If you are truly trying to debug an app & identify 
places that cause faults, the SIGNAL method should be used by the app. 
That way, additional info such as traceback & arguments can be captured. 

---

After thinking about it for a while, it seems to me that the kernel logging options
should be orthoginal to the user SIGNAL option. A site should be able to select
NOPRINT/RATE-LOGGING/FULL_LOGGING. Independently, the user to be able to select 
SIGNAL/NO_SIGNAL/PRINTALL. 

The kernel logging option should NOT be a task attribute. Just have
a static flag that controls logging. The value of the flag is 
NOPRINT/RATEPRINT/FULLPRINT. Default should be NOPRINT. This option should
be able to be changed via operator command (/proc).

Independently, users might want to select SIGNAL/NOSIGNAL/(PRINT?) 
for faults from their application. 


> 
> Does anyone else have an opinion on the rate limited logging for the
> unaligned and fpswa handlers?  Some people have told me that they don't
> think it's useful for admins or users to have some of the messages but not
> all of them.
> 
> Thanks,
> Jesse
> 
> On Tue, 9 Oct 2001, David Mosberger wrote:
> 
> > >>>>> On Tue, 9 Oct 2001 10:38:57 -0700, Jesse Barnes <jbarnes@sgi.com> said:
> > 
> >   Jesse> Wouldn't that mean you could only do one at a time,
> >   Jesse> i.e. you'd be stuck with the rate limiting code even if you
> >   Jesse> just wanted a signal, since there'd be no way to say NOPRINT
> >   Jesse> | SIGFPE?  I'm really just trying to fill the needs of our
> >   Jesse> application programmers, who say they want to get all the
> >   Jesse> messages and/or get a signal.
> > 
> > No, I don't think so:
> > 
> > 	DEFAULT:	log message (with rate limit)
> > 	NOPRINT:	be quiet about fixups (not rate limited)
> > 	SIGNAL:		send signal (not rate limited)
> > 	PRINTALL:	log message (not rate limited)
> > 
> > In other words, the rate-limiting only applies for the DEFAULT setting.
> > 
> > 	--david
> > 
> 
> 
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64
> 


-- 
Thanks

Jack Steiner    (651-683-5302)   (vnet 233-5302)      steiner@sgi.com

Re: [Linux-ia64] Re: prctl patch for fpu faults

[n0ano]

It depends upon the frequency that the FPSWA and unaligned faults
occur.  My experience is that, if you get any of these messages, you
get a lot o f them.  I like the 4 options David proposes, this
gives you the flexibility to manage these events in any way you
wish.  I like to run with the default (rate limited messages) setting -
if any messages come out I know there is something that needs to
be looked at but the system's `printk' buffer doesn't get flooded
with duplicated messages.

On Tue, Oct 09, 2001 at 02:40:49PM -0700, Jesse Barnes wrote:
> What if I were to get rid of the rate limited logging for both the
> unaligned and fpswa handlers?  Then there could just be a NOPRINT option
> and a signal option for each; the default behavior would be to log all
> messages.  If you'd rather not get rid of it, then I'll just send a patch
> to enable NOPRINT for fpswa (similar to what the unaligned handler does
> now) and a signal option.
> 
> Does anyone else have an opinion on the rate limited logging for the
> unaligned and fpswa handlers?  Some people have told me that they don't
> think it's useful for admins or users to have some of the messages but not
> all of them.
> 
> Thanks,
> Jesse
> 
> On Tue, 9 Oct 2001, David Mosberger wrote:
> 
> > >>>>> On Tue, 9 Oct 2001 10:38:57 -0700, Jesse Barnes <jbarnes@sgi.com> said:
> > 
> >   Jesse> Wouldn't that mean you could only do one at a time,
> >   Jesse> i.e. you'd be stuck with the rate limiting code even if you
> >   Jesse> just wanted a signal, since there'd be no way to say NOPRINT
> >   Jesse> | SIGFPE?  I'm really just trying to fill the needs of our
> >   Jesse> application programmers, who say they want to get all the
> >   Jesse> messages and/or get a signal.
> > 
> > No, I don't think so:
> > 
> > 	DEFAULT:	log message (with rate limit)
> > 	NOPRINT:	be quiet about fixups (not rate limited)
> > 	SIGNAL:		send signal (not rate limited)
> > 	PRINTALL:	log message (not rate limited)
> > 
> > In other words, the rate-limiting only applies for the DEFAULT setting.
> > 
> > 	--david
> > 
> 
> 
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64

-- 
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
n0ano@indstorage.com
Ph: 303/652-0870x117

Re: [Linux-ia64] Re: prctl patch for fpu faults

[Jesse Barnes]

Alright, I'll put a patch together that has noprint and signal options for
the unaligned and fpswa faults.  The current, rate limited output will be
the default.

Jesse

On Wed, 10 Oct 2001, Jack Steiner wrote:

> > 
> > What if I were to get rid of the rate limited logging for both the
> > unaligned and fpswa handlers?  Then there could just be a NOPRINT option
> > and a signal option for each; the default behavior would be to log all
> > messages.  If you'd rather not get rid of it, then I'll just send a patch
> > to enable NOPRINT for fpswa (similar to what the unaligned handler does
> > now) and a signal option.
> 
> IMHO, the default for FPSWA fault (& probably unaligned access) should be OFF.
> Lots of apps cause FP faults. AIM7, for example, causes faults at a fairly high
> rate. I doubt that any server site would like to see the log polluted with 
> these errors - especially since there is no way to identify the offending app.
> 
> There should be a way a site can change the default logging behavior & have it
> apply to ALL tasks.. 
> 
> 
> Remember that FPSWA is invoked for numerous reasons that are NOT necessarily 
> errors in the application. (AIM7 generates FPSWA faults when it divides a
> very small number by 2.0). Intel doesnt even specify all the conditions that cause
> FPSWA to be invoked.
> 
> As far as rate limited vs full logging, I like rate limited. Otherwise, you can
> flood the system with messages. If you are truly trying to debug an app & identify 
> places that cause faults, the SIGNAL method should be used by the app. 
> That way, additional info such as traceback & arguments can be captured. 
> 
> ---
> 
> After thinking about it for a while, it seems to me that the kernel logging options
> should be orthoginal to the user SIGNAL option. A site should be able to select
> NOPRINT/RATE-LOGGING/FULL_LOGGING. Independently, the user to be able to select 
> SIGNAL/NO_SIGNAL/PRINTALL. 
> 
> The kernel logging option should NOT be a task attribute. Just have
> a static flag that controls logging. The value of the flag is 
> NOPRINT/RATEPRINT/FULLPRINT. Default should be NOPRINT. This option should
> be able to be changed via operator command (/proc).
> 
> Independently, users might want to select SIGNAL/NOSIGNAL/(PRINT?) 
> for faults from their application. 
> 
> 
> > 
> > Does anyone else have an opinion on the rate limited logging for the
> > unaligned and fpswa handlers?  Some people have told me that they don't
> > think it's useful for admins or users to have some of the messages but not
> > all of them.
> > 
> > Thanks,
> > Jesse
> > 
> > On Tue, 9 Oct 2001, David Mosberger wrote:
> > 
> > > >>>>> On Tue, 9 Oct 2001 10:38:57 -0700, Jesse Barnes <jbarnes@sgi.com> said:
> > > 
> > >   Jesse> Wouldn't that mean you could only do one at a time,
> > >   Jesse> i.e. you'd be stuck with the rate limiting code even if you
> > >   Jesse> just wanted a signal, since there'd be no way to say NOPRINT
> > >   Jesse> | SIGFPE?  I'm really just trying to fill the needs of our
> > >   Jesse> application programmers, who say they want to get all the
> > >   Jesse> messages and/or get a signal.
> > > 
> > > No, I don't think so:
> > > 
> > > 	DEFAULT:	log message (with rate limit)
> > > 	NOPRINT:	be quiet about fixups (not rate limited)
> > > 	SIGNAL:		send signal (not rate limited)
> > > 	PRINTALL:	log message (not rate limited)
> > > 
> > > In other words, the rate-limiting only applies for the DEFAULT setting.
> > > 
> > > 	--david
> > > 
> > 
> > 
> > _______________________________________________
> > Linux-IA64 mailing list
> > Linux-IA64@linuxia64.org
> > http://lists.linuxia64.org/lists/listinfo/linux-ia64
> > 
> 
> 
> -- 
> Thanks
> 
> Jack Steiner    (651-683-5302)   (vnet 233-5302)      steiner@sgi.com
> 
> 
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64
> 

RE: [Linux-ia64] Re: prctl patch for fpu faults

[Mallick, Asit K]

David/Jesse,

I would like the default to be noprint. As Jack mentioned that there are
applications that will generate lots of these messages. These messages are
ok for development systems and debugging applications but for production
systems this creates problem. Most of the users want to run the applications
(production) that do not require changing the configuration. We have seen
people running applications on top of Linux and complaining about the
performance compared to other OSes. The performance difference is due to the
logging of these messages.

Thanks,
Asit


> -----Original Message-----
> From: Jesse Barnes [mailto:jbarnes@sgi.com]
> Sent: Wednesday, October 10, 2001 9:34 AM
> Cc: linux-ia64@linuxia64.org
> Subject: Re: [Linux-ia64] Re: prctl patch for fpu faults
> 
> 
> Alright, I'll put a patch together that has noprint and 
> signal options for
> the unaligned and fpswa faults.  The current, rate limited 
> output will be
> the default.
> 
> Jesse
> 
> On Wed, 10 Oct 2001, Jack Steiner wrote:
> 
> > > 
> > > What if I were to get rid of the rate limited logging for both the
> > > unaligned and fpswa handlers?  Then there could just be a 
> NOPRINT option
> > > and a signal option for each; the default behavior would 
> be to log all
> > > messages.  If you'd rather not get rid of it, then I'll 
> just send a patch
> > > to enable NOPRINT for fpswa (similar to what the 
> unaligned handler does
> > > now) and a signal option.
> > 
> > IMHO, the default for FPSWA fault (& probably unaligned 
> access) should be OFF.
> > Lots of apps cause FP faults. AIM7, for example, causes 
> faults at a fairly high
> > rate. I doubt that any server site would like to see the 
> log polluted with 
> > these errors - especially since there is no way to identify 
> the offending app.
> > 
> > There should be a way a site can change the default logging 
> behavior & have it
> > apply to ALL tasks.. 
> > 
> > 
> > Remember that FPSWA is invoked for numerous reasons that 
> are NOT necessarily 
> > errors in the application. (AIM7 generates FPSWA faults 
> when it divides a
> > very small number by 2.0). Intel doesnt even specify all 
> the conditions that cause
> > FPSWA to be invoked.
> > 
> > As far as rate limited vs full logging, I like rate 
> limited. Otherwise, you can
> > flood the system with messages. If you are truly trying to 
> debug an app & identify 
> > places that cause faults, the SIGNAL method should be used 
> by the app. 
> > That way, additional info such as traceback & arguments can 
> be captured. 
> > 
> > ---
> > 
> > After thinking about it for a while, it seems to me that 
> the kernel logging options
> > should be orthoginal to the user SIGNAL option. A site 
> should be able to select
> > NOPRINT/RATE-LOGGING/FULL_LOGGING. Independently, the user 
> to be able to select 
> > SIGNAL/NO_SIGNAL/PRINTALL. 
> > 
> > The kernel logging option should NOT be a task attribute. Just have
> > a static flag that controls logging. The value of the flag is 
> > NOPRINT/RATEPRINT/FULLPRINT. Default should be NOPRINT. 
> This option should
> > be able to be changed via operator command (/proc).
> > 
> > Independently, users might want to select SIGNAL/NOSIGNAL/(PRINT?) 
> > for faults from their application. 
> > 
> > 
> > > 
> > > Does anyone else have an opinion on the rate limited 
> logging for the
> > > unaligned and fpswa handlers?  Some people have told me 
> that they don't
> > > think it's useful for admins or users to have some of the 
> messages but not
> > > all of them.
> > > 
> > > Thanks,
> > > Jesse
> > > 
> > > On Tue, 9 Oct 2001, David Mosberger wrote:
> > > 
> > > > >>>>> On Tue, 9 Oct 2001 10:38:57 -0700, Jesse Barnes 
> <jbarnes@sgi.com> said:
> > > > 
> > > >   Jesse> Wouldn't that mean you could only do one at a time,
> > > >   Jesse> i.e. you'd be stuck with the rate limiting 
> code even if you
> > > >   Jesse> just wanted a signal, since there'd be no way 
> to say NOPRINT
> > > >   Jesse> | SIGFPE?  I'm really just trying to fill the 
> needs of our
> > > >   Jesse> application programmers, who say they want to 
> get all the
> > > >   Jesse> messages and/or get a signal.
> > > > 
> > > > No, I don't think so:
> > > > 
> > > > 	DEFAULT:	log message (with rate limit)
> > > > 	NOPRINT:	be quiet about fixups (not rate limited)
> > > > 	SIGNAL:		send signal (not rate limited)
> > > > 	PRINTALL:	log message (not rate limited)
> > > > 
> > > > In other words, the rate-limiting only applies for the 
> DEFAULT setting.
> > > > 
> > > > 	--david
> > > > 
> > > 
> > > 
> > > _______________________________________________
> > > Linux-IA64 mailing list
> > > Linux-IA64@linuxia64.org
> > > http://lists.linuxia64.org/lists/listinfo/linux-ia64
> > > 
> > 
> > 
> > -- 
> > Thanks
> > 
> > Jack Steiner    (651-683-5302)   (vnet 233-5302)      
> steiner@sgi.com
> > 
> > 
> > _______________________________________________
> > Linux-IA64 mailing list
> > Linux-IA64@linuxia64.org
> > http://lists.linuxia64.org/lists/listinfo/linux-ia64
> > 
> 
> 
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64
> 

RE: [Linux-ia64] Re: prctl patch for fpu faults

[David Mosberger]

>>>>> On Wed, 10 Oct 2001 13:18:38 -0700, "Mallick, Asit K" <asit.k.mallick@intel.com> said:

  Asit> David/Jesse, I would like the default to be noprint. As Jack
  Asit> mentioned that there are applications that will generate lots
  Asit> of these messages. These messages are ok for development
  Asit> systems and debugging applications but for production systems
  Asit> this creates problem. Most of the users want to run the
  Asit> applications (production) that do not require changing the
  Asit> configuration.

It's fine by me if distributors set things up such that they're
disabled by default, but for the kernel I'm releasing, I'll keep them
turned on.  It's just too easy to forget about them otherwise.  And a
program that accidentally generates tons of unaligned faults or fpswa
faults will perform *a lot* worse than a program that occasionally
generates a log message.

  Asit> We have seen people running applications on top of Linux and
  Asit> complaining about the performance compared to other OSes. The
  Asit> performance difference is due to the logging of these
  Asit> messages.

Can you be more specific?  A machine should easily tolerate a rate of
one logged message per second, so if this makes a significant
performance difference, that would be strange.

	--david

Re: [Linux-ia64] Re: prctl patch for fpu faults

[Keith Fish]

"Mallick, Asit K" wrote:
> 
> David/Jesse,
> 
> I would like the default to be noprint. As Jack mentioned that there are
> applications that will generate lots of these messages. These messages are
> ok for development systems and debugging applications but for production
> systems this creates problem. Most of the users want to run the applications
> (production) that do not require changing the configuration. We have seen
> people running applications on top of Linux and complaining about the
> performance compared to other OSes. The performance difference is due to the
> logging of these messages.

Really?  I would have thought the rate-limiting mode would reduce the logging
(printing) to noise relative to the (huge) overhead of the traps.

Re: [Linux-ia64] Re: prctl patch for fpu faults

[David Mosberger]

>>>>> On Wed, 10 Oct 2001 08:59:36 -0500 (CDT), Jack Steiner <steiner@sgi.com> said:

  Jack> There should be a way a site can change the default logging
  Jack> behavior & have it apply to ALL tasks..

I agree.  In theory, if you can change the behavior of "init", you'll
change the behavior of all subsequent tasks (the settings are
inherited across fork).  If you're willing to hack /etc/inittab, you
could probably do that with the "prctl" utility today (or perhaps even
with prctl + a suitable kernel command line), but none of these
solutions seem to be very pretty.  Perhaps someone can come up with a
cleaner solution?

	--david

Re: [Linux-ia64] Re: prctl patch for fpu faults

[Jesse Barnes]

I was thinking of hacking up the 'prctl' tool to take a PID as an
argument, that way it could set the flags for any task.  It would allow
an initscript to set init's flags, among other things.  Would such a
change qualify as a cleaner solution?

Jesse

On Wed, 10 Oct 2001, David Mosberger wrote:

> >>>>> On Wed, 10 Oct 2001 08:59:36 -0500 (CDT), Jack Steiner <steiner@sgi.com> said:
> 
>   Jack> There should be a way a site can change the default logging
>   Jack> behavior & have it apply to ALL tasks..
> 
> I agree.  In theory, if you can change the behavior of "init", you'll
> change the behavior of all subsequent tasks (the settings are
> inherited across fork).  If you're willing to hack /etc/inittab, you
> could probably do that with the "prctl" utility today (or perhaps even
> with prctl + a suitable kernel command line), but none of these
> solutions seem to be very pretty.  Perhaps someone can come up with a
> cleaner solution?
> 
> 	--david
> 

Re: [Linux-ia64] Re: prctl patch for fpu faults

[David Mosberger]

>>>>> On Wed, 10 Oct 2001 15:31:22 -0700, Jesse Barnes <jbarnes@sgi.com> said:

  Jesse> I was thinking of hacking up the 'prctl' tool to take a PID
  Jesse> as an argument, that way it could set the flags for any task.
  Jesse> It would allow an initscript to set init's flags, among other
  Jesse> things.  Would such a change qualify as a cleaner solution?

Yes, but how do you change the settings for the target process?
prctl(2) can only change the setting of the calling process (there is
no pid argument).  You can't do it via ptrace() either.

	--david

Re: [Linux-ia64] Re: prctl patch for fpu faults

[Khalid Aziz]

That sounds interesting. You could use it on init task as David
suggested and set the behavior for all tasks. But how would you
implement it form a user space tool like "prctl". sys_prctl() operates
on the current task only. Are you planning to add another system call?

--
Khalid

Jesse Barnes wrote:
> 
> I was thinking of hacking up the 'prctl' tool to take a PID as an
> argument, that way it could set the flags for any task.  It would allow
> an initscript to set init's flags, among other things.  Would such a
> change qualify as a cleaner solution?
> 
> Jesse
> 

==================================
Khalid Aziz                              Linux Systems Operation R&D
(970)898-9214                                        Hewlett-Packard
khalid@fc.hp.com                                    Fort Collins, CO

Re: [Linux-ia64] Re: prctl patch for fpu faults

[Jesse Barnes]

Can't prctl take up to 5 args though?  If binary compatibility were an
issue, a new prctl could be made that accepts a pid as well, right?

Jesse

On Wed, 10 Oct 2001, David Mosberger wrote:

> >>>>> On Wed, 10 Oct 2001 15:31:22 -0700, Jesse Barnes <jbarnes@sgi.com> said:
> 
>   Jesse> I was thinking of hacking up the 'prctl' tool to take a PID
>   Jesse> as an argument, that way it could set the flags for any task.
>   Jesse> It would allow an initscript to set init's flags, among other
>   Jesse> things.  Would such a change qualify as a cleaner solution?
> 
> Yes, but how do you change the settings for the target process?
> prctl(2) can only change the setting of the calling process (there is
> no pid argument).  You can't do it via ptrace() either.
> 
> 	--david
> 

Re: [Linux-ia64] Re: prctl patch for fpu faults

[David Mosberger]

>>>>> On Wed, 10 Oct 2001 15:57:21 -0700, Jesse Barnes <jbarnes@sgi.com> said:

  Jesse> Can't prctl take up to 5 args though?  If binary
  Jesse> compatibility were an issue, a new prctl could be made that
  Jesse> accepts a pid as well, right?

The latter seems cleaner, but someone would have to fight the battle
to get this into the platform-independent portion of the kernel (and
worry about all the security issues that ptrace has to worry about,
etc).  If you want to pursue this, that would be great.  But the
discussion should involve the linux-kernel list in that case.

	--david

RE: [Linux-ia64] Re: prctl patch for fpu faults

[Mallick, Asit K]

> Can you be more specific?  A machine should easily tolerate a rate of
> one logged message per second, so if this makes a significant
> performance difference, that would be strange.
> 
We saw a 2-5% performance degradation of specfp benchmarks when the logging
was enabled. I can take a look at this again and see how often the FPSWA
messages are getting logged.

Thanks,
Asit

RE: [Linux-ia64] Re: prctl patch for fpu faults

[David Mosberger]

>>>>> On Wed, 10 Oct 2001 20:11:58 -0700, "Mallick, Asit K" <asit.k.mallick@intel.com> said:

  >> Can you be more specific?  A machine should easily tolerate a
  >> rate of one logged message per second, so if this makes a
  >> significant performance difference, that would be strange.

  Asit> We saw a 2-5% performance degradation of specfp benchmarks
  Asit> when the logging was enabled. I can take a look at this again
  Asit> and see how often the FPSWA messages are getting logged.

On which one?  Speed or throughput?

	--david