From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Andy Lutomirski <luto@kernel.org>, Dave Hansen <dave@sr71.net>,
Andrew Morton <akpm@linux-foundation.org>,
Oleg Nesterov <oleg@redhat.com>
Subject: Re: [PATCH] sched, s390: Fix the fallout of increasing the offset of 'thread_struct' within 'task_struct'
Date: Mon, 20 Jul 2015 10:56:00 +0200 [thread overview]
Message-ID: <20150720105600.79b10fe4@mschwide> (raw)
In-Reply-To: <20150720083847.GC12468@gmail.com>
On Mon, 20 Jul 2015 10:38:47 +0200
Ingo Molnar <mingo@kernel.org> wrote:
>
> * Martin Schwidefsky <schwidefsky@de.ibm.com> wrote:
>
> > diff --git a/arch/s390/kernel/entry.S b/arch/s390/kernel/entry.S
> > index 3238893..84062e7 100644
> > --- a/arch/s390/kernel/entry.S
> > +++ b/arch/s390/kernel/entry.S
> > @@ -178,17 +178,21 @@ _PIF_WORK = (_PIF_PER_TRAP)
> > */
> > ENTRY(__switch_to)
> > stmg %r6,%r15,__SF_GPRS(%r15) # store gprs of prev task
> > - stg %r15,__THREAD_ksp(%r2) # store kernel stack of prev
> > - lg %r4,__THREAD_info(%r2) # get thread_info of prev
> > - lg %r5,__THREAD_info(%r3) # get thread_info of next
> > + lgr %r1,%r2
> > + aghi %r1,__TASK_thread # thread_struct of prev task
> > + lg %r4,__TASK_thread_info(%r2) # get thread_info of prev
> > + lg %r5,__TASK_thread_info(%r3) # get thread_info of next
> > + stg %r15,__THREAD_ksp(%r1) # store kernel stack of prev
> > + lgr %r1,%r3
> > + aghi %r1,__TASK_thread # thread_struct of next task
> > lgr %r15,%r5
> > aghi %r15,STACK_INIT # end of kernel stack of next
> > stg %r3,__LC_CURRENT # store task struct of next
> > stg %r5,__LC_THREAD_INFO # store thread info of next
> > stg %r15,__LC_KERNEL_STACK # store end of kernel stack
> > + lg %r15,__THREAD_ksp(%r1) # load kernel stack of next
> > lctl %c4,%c4,__TASK_pid(%r3) # load pid to control reg. 4
> > mvc __LC_CURRENT_PID+4(4,%r0),__TASK_pid(%r3) # store pid of next
> > - lg %r15,__THREAD_ksp(%r3) # load kernel stack of next
> > lmg %r6,%r15,__SF_GPRS(%r15) # load gprs of next task
> > br %r14
>
> Btw., I think we'd be slightly better off with the variant I sent: that way the
> offset arithmetics are done in C code and are ready in the relevant registers by
> the time they are used in __switch_to().
If we save any instruction then not many, we are trading additional parameter
passing vs. four additional instructions in __switch_to. With this variant
the fallout is kept at a minimum which I would prefer at this point.
> >
> > @@ -417,6 +421,7 @@ ENTRY(pgm_check_handler)
> > LAST_BREAK %r14
> > lg %r15,__LC_KERNEL_STACK
> > lg %r14,__TI_task(%r12)
> > + aghi %r14,__TASK_thread # pointer to thread_struct
> > lghi %r13,__LC_PGM_TDB
> > tm __LC_PGM_ILC+2,0x02 # check for transaction abort
> > jz 2f
>
> Don't we also need the chunk I have:
>
> @@ -448,6 +449,7 @@ ENTRY(pgm_check_handler)
> nill %r10,0x007f
> sll %r10,2
> je .Lsysc_return
> + ahi %r14,-__TASK_thread_struct # r14 now points to 'current'
> lgf %r1,0(%r10,%r1) # load address of handler routine
> lgr %r2,%r11 # pass pointer to pt_regs
> basr %r14,%r1 # branch to interrupt-handler
>
> Because the 'basr' line relies on 'r14' having task_struct, I think?
>
> But I don't really know what I'm talking about here ...
The basr instruction is one of the function calling instructions and
%r14 is used for the return address. Between function calls the register
is basically free. So far it is used for the task_struct pointer
(the code following the "lg %r14,__TI_task(%r12)"). What I noticed is
that the pointer is only used to access the embedded thread_struct.
To get from the task_struct to a thread_struct a single aghi is
needed. The rest is moving stuff around in asm-offsets.c
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
next prev parent reply other threads:[~2015-07-20 8:56 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-18 3:18 [GIT PULL] x86 fixes Ingo Molnar
2015-07-20 7:20 ` Heiko Carstens
2015-07-20 8:00 ` [PATCH] sched, s390: Fix the fallout of increasing the offset of 'thread_struct' within 'task_struct' Ingo Molnar
2015-07-20 8:12 ` Martin Schwidefsky
2015-07-20 8:38 ` Ingo Molnar
2015-07-20 8:56 ` Martin Schwidefsky [this message]
2015-07-20 8:20 ` [PATCH] s390, sched: Fix thread_struct move fallout to __switch_to() Ingo Molnar
2015-07-20 8:33 ` Martin Schwidefsky
2015-07-20 8:34 ` Ingo Molnar
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=20150720105600.79b10fe4@mschwide \
--to=schwidefsky@de.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=dave@sr71.net \
--cc=heiko.carstens@de.ibm.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=oleg@redhat.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).