From: Peter Zijlstra <peterz@infradead.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: "Nikita V. Youshchenko" <yoush@cs.msu.su>,
LKML <linux-kernel@vger.kernel.org>,
linux-rt-users <linux-rt-users@vger.kernel.org>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Jason Wessel <jason.wessel@windriver.com>,
lasaine@lvk.cs.msu.su
Subject: Re: [ANNOUNCE] 3.0-rt4
Date: Thu, 28 Jul 2011 10:43:51 +0200 [thread overview]
Message-ID: <1311842631.5890.208.camel@twins> (raw)
In-Reply-To: <alpine.LFD.2.02.1107280945080.2660@ionos>
On Thu, 2011-07-28 at 10:06 +0200, Thomas Gleixner wrote:
> On Thu, 28 Jul 2011, Nikita V. Youshchenko wrote:
>
> > > The list of disabled config option is now:
> > >
> > > - CONFIG_HIGHMEM [ see the mess it created in 33-rt ]
> >
> > Could someone please point me to information on this?
> >
> > In our setup, we do use PREEMPT_RT + HIGHMEM, on .33 for now (but want to
> > upgrade because of new hardware support issues with .33). Up to now, we
> > did not face any issues related to PREEMPT_RT + HIGHMEM combination.
>
> Yes, it works in 33-rt, but the way it's implemented is a horrible
> hack. I had not enough capacity to implement that cleanly for 3.0-rt,
> so I simply dropped it for now. The preliminary patches are there
> (mainly distangling the disable_pagefault logic), so it should not be
> that hard.
In fact, with migrate_disable() existing one could play games with
kmap_atomic. You could save/restore the kmap_atomic slots on context
switch (if there are any in use of course), this should be esp easy now
that we have a kmap_atomic stack.
Something like the below.. it wants replacing all the preempt_disable()
stuff with pagefault_disable() && migrate_disable() of course, but then
you can flip kmaps around like below.
---
arch/x86/kernel/process_32.c | 35 +++++++++++++++++++++++++++++++++++
include/linux/sched.h | 4 ++++
2 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index a3d0dc5..5ad6a02 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -348,6 +348,41 @@ __switch_to(struct task_struct *prev_p, struct task_struct *next_p)
task_thread_info(next_p)->flags & _TIF_WORK_CTXSW_NEXT))
__switch_to_xtra(prev_p, next_p, tss);
+#if defined PREEMPT_RT_FULL && defined CONFIG_HIGHMEM
+ /*
+ * Save @prev's kmap_atomic stack
+ */
+ prev_p->kmap_idx = __this_cpu_read(__kmap_atomic_idx);
+ if (unlikely(prev_p->kmap_idx)) {
+ int i;
+
+ for (i = 0; i < prev_p->kmap_idx; i++) {
+ int idx = i + KM_TYPE_NR * smp_processor_id();
+
+ pte_t *ptep = kmap_pte - idx;
+ prev_p->kmap_pte[i] = *ptep;
+ kpte_clear_flush(ptep, __fix_to_virt(FIX_KMAP_BEGIN + idx));
+ }
+
+ __this_cpu_write(__kmap_atomic_idx, 0);
+ }
+
+ /*
+ * Restore @next_p's kmap_atomic stack
+ */
+ if (unlikely(next_p->kmap_idx)) {
+ int i;
+
+ __this_cpu_write(__kmap_atomic_idx, next_p->kmap_idx);
+
+ for (i = 0; i < next_p->kmap_idx; i++) {
+ int idx = i + KM_TYPE_NR * smp_processor_id();
+
+ set_pte(kmap_ptr - idx, next_p->kmap_pte[i]);
+ }
+ }
+#endif
+
/* If we're going to preload the fpu context, make sure clts
is run while we're batching the cpu state updates. */
if (preload_fpu)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 341a4d7..2db2701 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1570,6 +1570,10 @@ struct task_struct {
#ifdef CONFIG_HAVE_HW_BREAKPOINT
atomic_t ptrace_bp_refcnt;
#endif
+#if defined PREEMPT_RT_FULL && defined CONFIG_HIGHMEM
+ int kmap_idx;
+ pte_t kmap_pte[KM_TYPE_NR];
+#endif
};
/* Future-safe accessor for struct task_struct's cpus_allowed. */
next prev parent reply other threads:[~2011-07-28 8:44 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-27 21:37 [ANNOUNCE] 3.0-rt4 Thomas Gleixner
2011-07-27 21:57 ` Frank Rowand
2011-07-27 22:05 ` Thomas Gleixner
2011-07-27 22:27 ` Frank Rowand
2011-07-28 7:33 ` Nikita V. Youshchenko
2011-07-28 8:06 ` Thomas Gleixner
2011-07-28 8:24 ` Nikita V. Youshchenko
2011-07-28 8:44 ` Peter Zijlstra
2011-07-28 8:51 ` Nikita V. Youshchenko
2011-07-28 9:21 ` Anca Emanuel
2011-07-28 16:10 ` Thomas Gleixner
2011-07-28 9:37 ` Thomas Gleixner
2011-07-28 8:43 ` Peter Zijlstra [this message]
2011-07-28 9:41 ` Yong Zhang
2011-07-28 9:41 ` Yong Zhang
2011-07-28 9:49 ` Thomas Gleixner
2011-07-28 11:22 ` N, Mugunthan V
2011-07-28 11:36 ` Thomas Gleixner
2011-07-28 15:59 ` hermann
2011-07-28 17:41 ` Paul E. McKenney
2011-07-28 17:43 ` Thomas Gleixner
2011-07-28 18:32 ` Paul E. McKenney
2011-07-28 19:05 ` Thomas Gleixner
2011-07-28 19:34 ` Paul E. McKenney
2011-07-28 20:29 ` Paul E. McKenney
2011-07-28 17:42 ` Jason Wessel
2011-07-28 17:49 ` Thomas Gleixner
2011-07-28 19:16 ` Fernando Lopez-Lezcano
2011-07-28 19:36 ` Thomas Gleixner
2011-07-29 0:13 ` Fernando Lopez-Lezcano
2011-07-28 21:22 ` Peter Zijlstra
2011-07-28 21:22 ` Peter Zijlstra
2011-07-28 22:55 ` Pekka Enberg
2011-07-29 0:17 ` Fernando Lopez-Lezcano
2011-08-04 8:36 ` [tip:core/urgent] slab, lockdep: Annotate the locks before using them tip-bot for Peter Zijlstra
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=1311842631.5890.208.camel@twins \
--to=peterz@infradead.org \
--cc=jason.wessel@windriver.com \
--cc=lasaine@lvk.cs.msu.su \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=yoush@cs.msu.su \
/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.