Date: Wed, 9 Aug 2006 09:24:40 -0700
From: "Luck, Tony" <tony.luck@intel.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Jes Sorensen <jes@sgi.com>, linux-kernel@vger.kernel.org
Subject: Re: How to lock current->signal->tty
Message-ID: <20060809162440.GA14143@intel.com>
References: <1155050242.5729.88.camel@localhost.localdomain> <44D8A97B.30607@linux.intel.com> <1155051876.5729.93.camel@localhost.localdomain> <20060808164127.GA11392@intel.com> <1155059405.5729.103.camel@localhost.localdomain> <yq0u04mtjni.fsf@jaguar.mkp.net> <1155120250.5729.146.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1155120250.5729.146.camel@localhost.localdomain>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1192
Lines: 26

On Wed, Aug 09, 2006 at 11:44:10AM +0100, Alan Cox wrote:
> 
> The users won't see them anyway, they are hidden behind the GUI.

I think that the majority of IA-64 users are connected to the target
machine via ssh login, rather than a directly connected VGA screen.
So they should see the message on their pty.

> > These messages are normally caused by userland code, so kprobes
> > probably wont do much good :)
> 
> Jes, read up on kprobes a little if you think its of no use in these
> kind of situations. A systemtap script to count/measure alignment fault
> rates and see who is causing the load isn't very hard to write.

But this does make sense ... the system administrator of a mainframe or
super-computer can (and arguably should) be monitoring resource
utilization and providing feedback to users on how to get the best
performance from their applications.

-Tony (currently at 90% rip out this message, 10% add the mutex lock/unlock).
-
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/