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
* 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
* 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)
> > > +{
> > > +
* 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,
> > > > +
* 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
* 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:
> 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
* 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
* 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
* 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 -
* 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 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:
> 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, 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
* 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
* 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,
> >>>>
>
* 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
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 &
* 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
* 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
* 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:
> 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:
> > 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
* 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:
> 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
* 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:
> > 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
* 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:
> > 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
* 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:
> > 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
* 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
* 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
* 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.
> &
* 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:
> >> 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
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
* 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
* 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
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
* 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
--
* 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
* 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
* 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
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
49 matches
Mail list logo
