hedules off, and wait_task_inactive did not account for this.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
linux/kernel/sched.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
--- linux/kernel/sched.c.orig
+++ linux/kern
* Blaisorblade <[EMAIL PROTECTED]> wrote:
> Hi Ingo, I'm the young UML hacker you met at OLS and who got your UML
> patches sent ;-)
>
> I've been studying your patch (and the whole Linux VM, indeed) in the
> past days, and I have some remarks, about the version of the code in
> 2.6.4-rc2-mm1
* Blaisorblade <[EMAIL PROTECTED]> wrote:
> Ok, I've been working for the past two weeks learning well the Linux
> VM, understanding the Ingo's remap_file_pages protection support and
> its various weakness (due to lack of time on his part), and splitting
> and finishing it.
>
> Here follow a
* David S. Miller <[EMAIL PROTECTED]> wrote:
> From: Blaisorblade <[EMAIL PROTECTED]>
> Date: Fri, 12 Aug 2005 20:56:11 +0200
>
> > However, I sent the initial tarball containing all them, so I hope
> > that will be useful.
>
> So not only did you spam the list with 40 patch postings, you sent
* Russell King - ARM Linux wrote:
> So, if you want to use this, then you should update the CONFIG_BUG text
> to include a warning to this effect:
>
> Warning: if CONFIG_BUG is turned off, and control flow reaches
> a BUG(), the system behaviour will be undefined.
>
> so that people
* Laurent Dufour wrote:
> Some architecture would like to be triggered when a memory area is moved
> through the mremap system call.
>
> This patch is introducing a new arch_remap mm hook which is placed in the
> path of mremap, and is called before the old area is unmapped (and the
> arch_unma
* Laurent Dufour wrote:
> Some processes (CRIU) are moving the vDSO area using the mremap system
> call. As a consequence the kernel reference to the vDSO base address is
> no more valid and the signal return frame built once the vDSO has been
> moved is not pointing to the new sigreturn address
* Laurent Dufour wrote:
> +static inline void arch_unmap(struct mm_struct *mm,
> + struct vm_area_struct *vma,
> + unsigned long start, unsigned long end)
> +{
> + if (start <= mm->context.vdso_base && mm->context.vdso_base < end)
> + mm->c
* Ingo Molnar wrote:
> > +#define __HAVE_ARCH_REMAP
> > +static inline void arch_remap(struct mm_struct *mm,
> > + unsigned long old_start, unsigned long old_end,
> > + unsigned long new_star
* Benjamin Herrenschmidt wrote:
> On Wed, 2015-03-25 at 19:36 +0100, Ingo Molnar wrote:
> > * Ingo Molnar wrote:
> >
> > > > +#define __HAVE_ARCH_REMAP
> > > > +static inline void arch_remap(struct mm_struct *mm,
> > > > +
* Benjamin Herrenschmidt wrote:
> > > +#define __HAVE_ARCH_REMAP
> > > +static inline void arch_remap(struct mm_struct *mm,
> > > + unsigned long old_start, unsigned long old_end,
> > > + unsigned long new_start, unsigned long new_end)
> > > +{
> > > +
* Laurent Dufour wrote:
> > I argue we should use the right condition to clear vdso_base: if
> > the vDSO gets at least partially unmapped. Otherwise there's
> > little point in the whole patch: either correctly track whether
> > the vDSO is OK, or don't ...
>
> That's a good option, but it
text.vdso_base = new_start;
> + else
> + mm->context.vdso_base = 0;
> + }
> +}
Oh my, that really looks awfully complex, as you predicted, and right
in every mremap() call.
I'm fine with your original, imperfect, KISS approach. Sorry abo
* Jeff Dike <[EMAIL PROTECTED]> wrote:
> cachemiss_thread should explicitly return 0 or error instead of
> task_ret_reg(current) (which is -ENOSYS anyway) because
> async_thread_helper is careful to put the return value in eax anyway.
oops, indeed! Thanks.
Ingo
--
n of
> ‘wait_for_completion_interruptible’ was here
> make[1]: *** [kernel/sched.o] Error 1
> make: *** [kernel] Error 2
does the patch below ontop of latest -git help?
Ingo
>
Subject: sched: fix fastcall mismatch in completion APIs
From: Ingo Molnar <[E
* Al Viro <[EMAIL PROTECTED]> wrote:
> in kernel/sched.c
>
> FWIW, I would simply kill the damn fastcall thing - right now the only
> user is uml/i386; everything else either has it #defined to nothing or
> (as i386 does) passes -mregparm=3 while having fastcall expand to
> __attribute__((reg
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
> > we should kill it there too.
> >
> > the only place where we should _please_ keep those annotations are for
> > functions that get called from assembly code. This makes l
a patch to do this already?
yes, attached. Ack?
Ingo
>
Subject: [patch] paravirt: mark assembly dependencies as fastcall
From: Ingo Molnar <[EMAIL PROTECTED]>
the 'fastcall removal' changes to paravirt.c were over-eager: they
removed fastcall annota
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > so this patch adds back fastcall annotations. This serves as
> > documentation for assembly calling-convention dependencies as well.
>
> You should rename it then to "asmcall" or something.
if then that should be a separate renaming patch.
I
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> >> You should rename it then to "asmcall" or something.
> >
> > if then that should be a separate renaming patch.
>
> Well you're asking for the ugly hacks for out of tree code. [...]
nice word-bending there. I'm asking for pre-existing annotations to
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
> > * Andi Kleen <[EMAIL PROTECTED]> wrote:
> >
> >
> >>>> You should rename it then to "asmcall" or something.
> >>>>
> >>> i
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 23, 2007 at 04:20:06PM +0200, Ingo Molnar wrote:
> >
> > * Andi Kleen <[EMAIL PROTECTED]> wrote:
> >
> > > >> You should rename it then to "asmcall" or something.
> &
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > [...] -pg should in theory work with -mregparms.
>
> last i checked it didnt work - i'll re-check that.
earlier gcc versions had problems with -mregparm and with -pg. I just
did a quick test with latest gcc and at a quick
* Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> When writing a big file to a ubd disk, everything in uml slows down to
> a crawl, even though CPU usage is minimal.
>
> So I wanted to try the latency tracer from -rt, but it doesn't compile
> with UML:
note that there are standalone patches as wel
* Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > so there's no forced need to use -rt.
>
> Ah, forgotten about that.
>
> Unfortunately the latency tracer patch doesn't compile either:
>
> CC kernel/latency_trace.o
> kernel/latency_trace.c:28:21: error: asm/rtc.h: No such file or director
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > CC kernel/latency_trace.o
> > kernel/latency_trace.c:28:21: error: asm/rtc.h: No such file or directory
> > kernel/latency_trace.c:63:3: error: #error Implement cycles_to_usecs.
> > kernel/latency_tra
* Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > it doesnt need it - turn IRQOFF_TRACING off.
>
> # CONFIG_CRITICAL_IRQSOFF_TIMING is not set
>
> This seems to be off.
>
> But latency_trace.c uses irqs_disabled_flags(), which is defined in
> only if CONFIG_TRACE_IRQFLAGS_SUPPORT is set.
>
>
* Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > On Wed, Nov 28, 2007 at 02:09:45PM +0100, Miklos Szeredi wrote:
> > > kernel/latency_trace.c:28:21: error: asm/rtc.h: No such file or directory
> >
> > For things like this, look at the host's asm/foo.h and see if it's
> > usable in UML (and contai
* Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > so you can define irqs_off_flags to always-0 and you should be able
> > to get pretty good traces still. It should have no functional
> > impact.
>
> OK, managed to make it compile, but then something goes wrong in
> tracer_alloc_bootmem().
try
* Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > OK, managed to make it compile, but then something goes wrong in
> > tracer_alloc_bootmem().
>
> It needs 32M, and uml has that much by default. Doh.
reduce MAX_TRACE to something like 1024 to make sure allocation is not
an issue. Do you still s
* Jeff Dike <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 28, 2007 at 04:35:12PM +0100, Miklos Szeredi wrote:
> > Something like:
> >
> > dd if=/host/tmp/bigfile of=/tmp/bigfile bs=1048576 count=100
> >
> > and run 'top' or 'watch something' in another terminal, which
> > sometimes completely stop
* Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> I can't say I'm understading these traces very well, but here's a
> snippet that looks a bit strange. I'm running 'while true; do date;
> done' in parallel with the dd.
>
> For some time it is doing 100% CPU as expected, then it goes into a
> sec
* Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > how come UML idled for 30 msecs here, while the workload was
> > supposed to be CPU-bound? It's not IO bound anywhere, right? No SMP
> > artifacts either, right?
>
> Yes. The UML kernel is UP, and I don't think 'date' or 'bash' want to
> do any
* Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > to get symbolic stack backdumps for the wakeup points, and add
> > trace_special_sym() calls to generate extra stackdump entries at
> > arbitrary places. schedule() does not have it right now - it might
> > make sense to add it.
>
> OK, this hel
* Jeff Dike <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 29, 2007 at 11:19:40AM +0100, Miklos Szeredi wrote:
> > date-7119 0 15636591us!: schedule (0 0)
> > bash-502 0 15643908us!: schedule (0 0)
> > bash-502 0 15646250us!: schedule (0 0)
>
> How exactly did you end u
* Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > heh :-) Scheduling isnt hard either - and looking at traces
> > (especially with mcount_enabled=1) certainly helps.
>
> I still don't know what mcount_enabled=1 should do. I didn't see any
> difference in the trace after enabling it.
if you bui
* Jeff Dike <[EMAIL PROTECTED]> wrote:
> git-x86, in commit 70aa1bd3839e3ec74ce65316528a82570e8de666, changed a
> lot of the sigcontext field names. This patch changes UML usage to
> match.
thanks, we indeed missed those. Should we carry this in x86.git, or
would you like to carry this in yo
* Jeff Dike <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 05, 2007 at 05:48:16PM +0100, Ingo Molnar wrote:
> > thanks, we indeed missed those. Should we carry this in x86.git, or
> > would you like to carry this in your UML tree?
>
> Probably better for it to go in x8
regparm calling convention. The fix is to introduce the "asmregparm"
attribute to mark such function prototypes with regparm(3). This is the
opposite of asmlinkage. [asmlinkage forced regparm(0)]
Ingo
---->
Subject: x86: fix UML calling convention
From: Ingo Molnar &
* Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> Thanks. Patch works, but needed to add asmregparm to the definitions
> as well, plus added default define into (updated
> patch below).
thanks, applied.
Ingo
-
Chec
* Hiroshi Shimamoto <[EMAIL PROTECTED]> wrote:
> Rui Sousa wrote:
> > On Thursday 4 September 2008 19:14, Hiroshi Shimamoto wrote:
> >> Ingo Molnar wrote:
> >>> * Rui Sousa <[EMAIL PROTECTED]> wrote:
> >>>> Hi,
> >>>>
>
* Renzo Davoli wrote:
> +/* test thread code. This thread is started only to test
> + * which features are provided by the linux kernel */
> +static int sysptvm_child(void *arg)
> +{
> + int *featurep=arg;
> + int p[2]={-1,-1};
> + pid_t pid=os_getpid();
> + if(ptrace(PTRACE_TRA
* Miklos Szeredi wrote:
> On Fri, 20 Mar 2009, Peter Zijlstra wrote:
> > On Thu, 2009-03-19 at 23:23 +0100, Miklos Szeredi wrote:
> > >
> > > This patch solves this by not scheduling on preempt_enable() after
> > > ptrace_stop() has woken up the tracer.
> >
> > Nice,.. however did you find thi
* Miklos Szeredi wrote:
> On Fri, 20 Mar 2009, Peter Zijlstra wrote:
> > On Fri, 2009-03-20 at 10:43 +0100, Miklos Szeredi wrote:
> > > Ingo,
> > >
> > > I tested this one, and I think it makes sense in any case as an
> > > optimization. It should also be good for -stable kernels.
> > >
> > >
* Miklos Szeredi wrote:
> On Fri, 20 Mar 2009, Ingo Molnar wrote:
> > > > The first line of attack for this problem is making
> > > > wait_task_inactive() sucks less, which shouldn't be too hard,
> > > > that unconditional 1 jiffy sleep is simp
* Miklos Szeredi wrote:
> This one incorporates comments from Oleg and Ingo. Please apply
> to 2.6.29 and 2.6.2[78]-stable trees.
The fix first needs to go upstream. There's an alternative patch
below. Would you mind to give it a test? Chances are that it will
make UML even faster than your
* Miklos Szeredi wrote:
> On Mon, 23 Mar 2009, Ingo Molnar wrote:
> > * Miklos Szeredi wrote:
> >
> > > This one incorporates comments from Oleg and Ingo. Please apply
> > > to 2.6.29 and 2.6.2[78]-stable trees.
> >
> > The fix first needs
* Oleg Nesterov wrote:
> On 03/23, Ingo Molnar wrote:
> >
> > There's an alternative patch
> > below. Would you mind to give it a test? Chances are that it will
> > make UML even faster than your fix.
> >
> > Ingo
> >
> > diff -
* H. Peter Anvin wrote:
> Borislav,
>
> We're tracking down an issue with the way system call arguments are
> handled on 32 bits. We have a solution for SYSENTER but not
> SYSCALL; fixing SYSCALL "properly" appears to be very difficult at
> best.
>
> So the question is: how much overhead w
49 matches
Mail list logo
