All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: "Fr馘駻ic Weisbecker" <fweisbec@gmail.com>
Cc: Andy Lutomirski <luto@amacapital.net>, X86 <x86@kernel.org>,
	linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Denys Vlasenko <dvlasenk@redhat.com>
Subject: context tracking vs. syscall_trace_leave & do_notify_resume loop
Date: Thu, 30 Apr 2015 21:30:24 -0400	[thread overview]
Message-ID: <5542D730.2050903@redhat.com> (raw)

Andy pointed out to me something I should have seen earlier: both
syscall_trace_leave and do_notify_resume call both user_exit()
and user_enter(), which has the potential to greatly increase the
cost of context tracking.

I believe (though it is hard to know for sure) there are legitimate
reasons why there is a loop around syscall_trace_leave and
do_notify_resume, but I strongly suspect the context tracking code
does not need to be in that loop.

I suspect it would be possible to stick a call to a new function
(return_to_user ?) right after the DISABLE_INTERRUPTS below, which
could be used to do the context tracking user_enter just once, and
later on also to load the user FPU context (patches I have sitting
around).

syscall_return:
        /* The IRETQ could re-enable interrupts: */
        DISABLE_INTERRUPTS(CLBR_ANY)
        TRACE_IRQS_IRETQ

Andy, Denys, do you guys see any issues with that idea?

I realize that would mean a RESTORE_EXTRA_REGS after that call
to return_to_user(), but it looks like that could be achieved
without making the code any worse than it already is :)

-- 
All rights reversed

             reply	other threads:[~2015-05-01  1:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-01  1:30 Rik van Riel [this message]
2015-05-01 15:55 ` context tracking vs. syscall_trace_leave & do_notify_resume loop Andy Lutomirski
2015-05-01 16:00   ` Rik van Riel
2015-05-01 16:05     ` Andy Lutomirski
2015-05-01 16:14       ` Rik van Riel
2015-05-01 16:16         ` Andy Lutomirski
2015-05-01 16:19           ` Rik van Riel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5542D730.2050903@redhat.com \
    --to=riel@redhat.com \
    --cc=dvlasenk@redhat.com \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.