linux-mips
[Top] [All Lists]

Re: [PATCH 0/2] MIPS: Move signal return trampolines off the stack.

To: David Daney <ddaney@caviumnetworks.com>
Subject: Re: [PATCH 0/2] MIPS: Move signal return trampolines off the stack.
From: David VomLehn <dvomlehn@cisco.com>
Date: Wed, 22 Apr 2009 11:31:29 -0700
Authentication-results: sj-dkim-4; header.From=dvomlehn@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );
Cc: linux-mips@linux-mips.org, Ralf Baechle <ralf@linux-mips.org>
Dkim-signature: v=1; a=rsa-sha256; q=dns/txt; l=985; t=1240425089; x=1241289089; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dvomlehn@cisco.com; z=From:=20David=20VomLehn=20<dvomlehn@cisco.com> |Subject:=20Re=3A=20[PATCH=200/2]=20MIPS=3A=20Move=20signal =20return=20trampolines=20off=20the=20stack. |Sender:=20; bh=kcR923mbTDjr9rXjt9rxXyMkAL/MrrcXZfofdE84y8k=; b=D1kzQCsT2goWlvE53eqvtHHIocMoiCV5xU1m5DVY6ENrDCrvJrgMLD8Sk+ up+Epbk/8AJPgGKMm1i3xiuNAnzoYVBYSkS5Re3vDa4WclC6wXF908g2nNhH puDFT0Ftso;
In-reply-to: <49EF5E58.2040901@caviumnetworks.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <49EE3B0F.3040506@caviumnetworks.com> <20090422180447.GC28623@cuplxvomd02.corp.sa.net> <49EF5E58.2040901@caviumnetworks.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.18 (2008-05-17)
On Wed, Apr 22, 2009 at 11:13:44AM -0700, David Daney wrote:
> David VomLehn wrote:
...
>> Only one comment, which I would not want to hold up acceptance:
>> based on some numbers sent out recently, it looks like the kernel is
>> experiencing some performance issues with exec() and I think this change will
>> make it slightly slower. You could avoid this by deferring installation of
>> the trampoline to the first use of a system call that registers a signal
>> handler.
>
> I should try to measure this too.  Although this is what x86 et al. do.  
> It is by far much simpler and less prone to bugs that trying to hook  
> into the system calls.  After an executable has had the chance to start  
> additional threads and establish arbitrary mappings things get 
> complicated.

I suspect the overhead is quite small and agree that hooking into the
system calls a bit risky. This might be better done as a phase two, if
at all.

> David Daney

David VomLehn

<Prev in Thread] Current Thread [Next in Thread>