From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757995AbZBZUWV (ORCPT ); Thu, 26 Feb 2009 15:22:21 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753618AbZBZUWF (ORCPT ); Thu, 26 Feb 2009 15:22:05 -0500 Received: from mx2.redhat.com ([66.187.237.31]:41299 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752920AbZBZUWE (ORCPT ); Thu, 26 Feb 2009 15:22:04 -0500 Date: Thu, 26 Feb 2009 21:19:05 +0100 From: Oleg Nesterov To: Vegard Nossum Cc: Ingo Molnar , Pekka Enberg , linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCH] signals: don't copy siginfo_t on dequeue Message-ID: <20090226201905.GA8548@redhat.com> References: <20090226184433.GA15644@damson.getinternet.no> <20090226185053.GD31413@elte.hu> <19f34abd0902261110n7b73eabdpf5b963594fc821c8@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19f34abd0902261110n7b73eabdpf5b963594fc821c8@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/26, Vegard Nossum wrote: > > 2009/2/26 Ingo Molnar : > > > > I.e. shouldnt we have seen a speedup, due to not having to copy > > the siginfo structure? I am puzzled by these numbers too. I can't understand how this patch can make any difference. > Actually, no. Because copy_siginfo() does not copy the whole (128 > byte) structure if the signal was generated by the user, just probably > the first 24 bytes or so. So I would expect the "kernel generated > signal" path to be faster, but that is not tested by my SIGUSR test. > > Besides, I think there is a small overhead in now having an extra > level of indirection for getting our hands on the signal number. But this all is nothing compared to the "real work" we have to do in order to handle the signal? setup_rt_frame, sys_rt_sigreturn... > But we might able to speed up the user->user case a little bit by > fixing sys_kill() not to use copy_siginfo() too. Yes. It would really, really nice to preallocate siginfo in sys_kill/etc and avoid the GFP_ATOMIC allocation in send_signal(). Unfortunaltely, this is not easy too. Because we can send the signal to pgrp or to all tasks. Oleg.