Re: [uml-devel] Patch v3

Hi List, hi Richard, Slight bump - we are now at 5.6Gbit. Same host hardware - 3.5GHz Athlon. This is an incremental on top of the last patchset from this week which tidies up further the SG and TSO/GSO code and enables it both way to the extent possible. Richard, I would like, if possible, 

Re: [uml-devel] Patch v3

I got the TSO and some offloads working for some (not all) cases of my patchsets. Preliminary speeds and feeds on iperf: [  4] local 192.168.98.1 port 5001 connected with 192.168.98.132 port 54838 [  4]  0.0-10.0 sec  4.78 GBytes  4.11 Gbits/sec As a comparison - kvm/qemu on same machine does

[uml-devel] [PATCH v3 2/2] High Performance Vector Network Driver

From: Anton Ivanov 1. Provides infrastructure for vector IO using recvmmsg/sendmmsg. 1.1. Multi-message read. 1.2. Multi-message write. 1.3. Optimized queue support for multi-packet enqueue/dequeue. 1.4. BQL/DQL support. 2. Implements transports for several

[uml-devel] Patch v3

Hi List, hi Richard, I found a logical error in the SG code. This revision fixes that. No other changes - the rest appears to work as it should in my testing. Brgds, A. -- Check out the vibrant tech community on one

[uml-devel] [PATCH v3 1/2] Epoll based IRQ controller

From: Anton Ivanov 1. Removes the need to walk the IRQ/Device list to determine who triggered the IRQ. 2. Improves scalability (up to several times performance improvement for cases with 10s of devices). 3. Improves UML baseline IO performance for one disk + one

Re: [uml-devel] [PATCH v3 0/6] um: Output messages to stderr and support quiet option

Masami, On Wed, May 17, 2017 at 7:13 PM, Masami Hiramatsu wrote: > Hello, > > Here is version 3 of um-quiet series. In this version > I just fixed some printf format issues. > > V2 is here. > > https://lkml.org/lkml/2017/5/8/35 > > This series fixes some boot time printf

Re: [uml-devel] [PATCH v3] UBD Improvements Phase 1

On 09/11/16 16:08, James McMechan wrote: > Hi > > I am not clear on the remainder/remainder_size would not a single offset > parameter work? rather than copying it off and back? Possible. The other alternative is to copy the remainder (if it exists) to the beginning of the buffer at the end

Re: [uml-devel] [PATCH v3] UBD Improvements Phase 1

Hi I am not clear on the remainder/remainder_size would not a single offset parameter work? rather than copying it off and back? also max_recs does not seem to used except to calculate max buffer size so would not using a buffer size be easier? something like bulk_req_read( int fd, struct

[uml-devel] [PATCH v3] UBD Improvements Phase 1

From: Anton Ivanov UBD at present is extremely slow because it handles only one request at a time in the IO thread and IRQ handler. The single request at a time is replaced by handling multiple requests as well as necessary workarounds for short reads/writes. Resulting

Re: [uml-devel] [PATCH v3 0/3] um: fix and extend FPU support

Am 20.05.2016 17:31 schrieb Eli Cooper : > > On 2016/4/5 5:42, Richard Weinberger wrote: > > Sorry for my late response. > > I'll put this now into -next and give it some testing. > > Ping? > > It has been some time but I don't see this in -next yet. Sorry, I'm late. It

Re: [uml-devel] [PATCH v3 0/3] um: fix and extend FPU support

On 2016/4/5 5:42, Richard Weinberger wrote: > Sorry for my late response. > I'll put this now into -next and give it some testing. Ping? It has been some time but I don't see this in -next yet. -- Mobile security can be

Re: [uml-devel] [PATCH v3 0/3] um: fix and extend FPU support

Am 19.03.2016 um 17:58 schrieb Eli Cooper: > This series first fixes a bug that results in corrupted FPU state after > invoking signal handlers. It also adds support for the extended processor > state (XSTATE) for x86_64 UML, especially the YMM registers used by AVX(2) > instructions. > > Tested

[uml-devel] [PATCH v3 3/3] um: add extended processor state save/restore support

This patch extends save_fp_registers() and restore_fp_registers() to use PTRACE_GETREGSET and PTRACE_SETREGSET with the XSTATE note type, adding support for new processor state extensions between context switches. When the new ptrace requests are unavailable, it falls back to the old

[uml-devel] [PATCH v3 2/3] um: extend fpstate to _xstate to support YMM registers

Extends fpstate to _xstate, in order to hold AVX/YMM registers. To avoid oversized stack frame, the following functions have been refactored by using malloc. - sig_handler_common - timer_real_alarm_handler Signed-off-by: Eli Cooper --- arch/um/os-Linux/signal.c | 28

[uml-devel] [PATCH v3 1/3] um: fix FPU state preservation around signal handlers

This patch makes UML saves/restores FPU state from/to the fpstate in pt_regs when setting up or returning from a signal stack, rather than calling ptrace directly. This ensures that FPU state is correctly preserved around signal handlers in a multi-threaded scenario. Signed-off-by: Eli Cooper

[uml-devel] [PATCH v3 0/3] um: fix and extend FPU support

This series first fixes a bug that results in corrupted FPU state after invoking signal handlers. It also adds support for the extended processor state (XSTATE) for x86_64 UML, especially the YMM registers used by AVX(2) instructions. Tested with a minimal multi-threaded FPU-intensive test

Re: [uml-devel] [PATCH v3 1/2] um: Do not set unsecure permission for temporary file

Acked-by: Tristan Schmelcher -- ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net

[uml-devel] [PATCH v3] EPOLL Interrupt Controller V2.0 - Work in Progress

Epoll based interrupt controller. IMPROVES: IO loop performance - no per fd lookups, allowing for 15% IO speedup in minimal config going to 100s of % with many devices - a N^N lookup is now replaced by a log(N) ADDS: True Write IRQ functionality OBSOLETES: The need to

Re: [uml-devel] [PATCH v3] um: Switch clocksource to hrtimers

On 02/11/15 10:01, Richard Weinberger wrote: > Am 02.11.2015 um 10:53 schrieb Anton Ivanov: >> [snip] >> > I'm pretty sure that you don't see the issue as your Jessy userspace uses > nanosleep periodically. There are quite a few things running so this may indeed be the case.

Re: [uml-devel] [PATCH v3] um: Switch clocksource to hrtimers

Am 02.11.2015 um 15:30 schrieb Anton Ivanov: > On 02/11/15 10:01, Richard Weinberger wrote: >> Am 02.11.2015 um 10:53 schrieb Anton Ivanov: >>> [snip] >>> >> I'm pretty sure that you don't see the issue as your Jessy userspace >> uses nanosleep periodically. > There are quite a few

Re: [uml-devel] [PATCH v3] um: Switch clocksource to hrtimers

I was testing under similar conditions (CPU pinning using taskset -c 0 on a multicore). I have removed it and run some retests - I cannot reproduce the hang at this point with my config I am going to run a defconfig and compare the results to see if this will give me any insights on the root

Re: [uml-devel] [PATCH v3] um: Switch clocksource to hrtimers

On 02/11/15 08:37, Richard Weinberger wrote: > Hi! > > Am 02.11.2015 um 09:14 schrieb Anton Ivanov: >> I was testing under similar conditions (CPU pinning using taskset -c 0 on a >> multicore). >> >> I have removed it and run some retests - I cannot reproduce the hang at this >> point with my

Re: [uml-devel] [PATCH v3] um: Switch clocksource to hrtimers

Hi! Am 02.11.2015 um 09:14 schrieb Anton Ivanov: > I was testing under similar conditions (CPU pinning using taskset -c 0 on a > multicore). > > I have removed it and run some retests - I cannot reproduce the hang at this > point with my config > > I am going to run a defconfig and compare

Re: [uml-devel] [PATCH v3] um: Switch clocksource to hrtimers

On 02/11/15 15:25, Richard Weinberger wrote: > Am 02.11.2015 um 15:30 schrieb Anton Ivanov: >> On 02/11/15 10:01, Richard Weinberger wrote: >>> Am 02.11.2015 um 10:53 schrieb Anton Ivanov: [snip] >>> I'm pretty sure that you don't see the issue as your Jessy userspace >>> uses

Re: [uml-devel] [PATCH v3] um: Switch clocksource to hrtimers

On 02/11/15 08:52, Richard Weinberger wrote: > Am 02.11.2015 um 09:41 schrieb Anton Ivanov: >> On 02/11/15 08:37, Richard Weinberger wrote: >>> Hi! >>> >>> Am 02.11.2015 um 09:14 schrieb Anton Ivanov: I was testing under similar conditions (CPU pinning using taskset -c 0 on a

Re: [uml-devel] [PATCH v3] um: Switch clocksource to hrtimers

[snip] >>> I'm pretty sure that you don't see the issue as your Jessy userspace uses >>> nanosleep periodically. >> There are quite a few things running so this may indeed be the case. >> >> What do you use for userspace (so I can try to reproduce this and debug it)? > Debian Squeeze amd64 with

Re: [uml-devel] [PATCH v3] um: Switch clocksource to hrtimers

Am 02.11.2015 um 09:41 schrieb Anton Ivanov: > On 02/11/15 08:37, Richard Weinberger wrote: >> Hi! >> >> Am 02.11.2015 um 09:14 schrieb Anton Ivanov: >>> I was testing under similar conditions (CPU pinning using taskset -c 0 on a >>> multicore). >>> >>> I have removed it and run some retests - I

Re: [uml-devel] [PATCH v3] um: Switch clocksource to hrtimers

Am 02.11.2015 um 09:57 schrieb Anton Ivanov: > On 02/11/15 08:52, Richard Weinberger wrote: >> Am 02.11.2015 um 09:41 schrieb Anton Ivanov: >>> On 02/11/15 08:37, Richard Weinberger wrote: Hi! Am 02.11.2015 um 09:14 schrieb Anton Ivanov: > I was testing under similar conditions

Re: [uml-devel] [PATCH v3] um: Switch clocksource to hrtimers

On 02/11/15 10:59, Anton Ivanov wrote: > On 02/11/15 10:01, Richard Weinberger wrote: >> Am 02.11.2015 um 10:53 schrieb Anton Ivanov: >>> [snip] >>> >> I'm pretty sure that you don't see the issue as your Jessy >> userspace uses nanosleep periodically. > There are quite a few things

Re: [uml-devel] [PATCH v3] um: Switch clocksource to hrtimers

On 02/11/15 10:01, Richard Weinberger wrote: > Am 02.11.2015 um 10:53 schrieb Anton Ivanov: >> [snip] >> > I'm pretty sure that you don't see the issue as your Jessy userspace uses > nanosleep periodically. There are quite a few things running so this may indeed be the case.

Re: [uml-devel] [PATCH v3] um: Switch clocksource to hrtimers

Am 31.10.2015 um 16:24 schrieb Thomas Meyer: > Am Samstag, den 31.10.2015, 16:21 +0100 schrieb Richard Weinberger: >> Am 31.10.2015 um 16:16 schrieb Thomas Meyer: >>> mhh. strange. I didn't see this behaviour on my machine, but my >>> machine >>> is a rare single core system so, likely a race

Re: [uml-devel] [PATCH v3] um: Switch clocksource to hrtimers

Am 31.10.2015 um 17:22 schrieb Anton Ivanov: > Richard, can you send me your config. Sure. It is basically a defconfig. > I have had it running for a couple of days before submission both under load > and idle it was doing OK. Well, what userspace did you try? I did some more tests, if

Re: [uml-devel] [PATCH v3] um: Switch clocksource to hrtimers

Am 31.10.2015 um 16:44 schrieb Thomas Meyer: > Am Samstag, den 31.10.2015, 16:30 +0100 schrieb Richard Weinberger: >> Am 31.10.2015 um 16:24 schrieb Thomas Meyer: >>> Am Samstag, den 31.10.2015, 16:21 +0100 schrieb Richard Weinberger: Am 31.10.2015 um 16:16 schrieb Thomas Meyer: > mhh.

Re: [uml-devel] [PATCH v3] um: Switch clocksource to hrtimers

On 31/10/15 19:08, Richard Weinberger wrote: > Am 31.10.2015 um 17:22 schrieb Anton Ivanov: >> Richard, can you send me your config. > Sure. It is basically a defconfig. I am dragging an old config from some work I did a while back. I will scrap it and do a defconfig build one I get back home (I

Re: [uml-devel] [PATCH v3] um: Switch clocksource to hrtimers

On Thu, Oct 29, 2015 at 7:23 AM, Anton Ivanov wrote: > I got the first patchset to build, it works very well on a single core > host or with CPU pinning of the UML - the performance gain is > 25%. > > However, I introduced a race somewhere along the way - it

Re: [uml-devel] [PATCH v3] um: Switch clocksource to hrtimers

Am Samstag, den 31.10.2015, 16:13 +0100 schrieb Richard Weinberger: > Am 31.10.2015 um 16:10 schrieb Thomas Meyer: > > Am Samstag, den 31.10.2015, 14:54 +0100 schrieb Richard Weinberger: > > > On Thu, Oct 29, 2015 at 7:23 AM, Anton Ivanov > > > wrote: > > > > I got

Re: [uml-devel] [PATCH v3] um: Switch clocksource to hrtimers

Am Samstag, den 31.10.2015, 16:21 +0100 schrieb Richard Weinberger: > Am 31.10.2015 um 16:16 schrieb Thomas Meyer: > > mhh. strange. I didn't see this behaviour on my machine, but my > > machine > > is a rare single core system so, likely a race condition while > > relaying > > the timer interrupt

Re: [uml-devel] [PATCH v3] um: Switch clocksource to hrtimers

Am Samstag, den 31.10.2015, 16:30 +0100 schrieb Richard Weinberger: > Am 31.10.2015 um 16:24 schrieb Thomas Meyer: > > Am Samstag, den 31.10.2015, 16:21 +0100 schrieb Richard Weinberger: > > > Am 31.10.2015 um 16:16 schrieb Thomas Meyer: > > > > mhh. strange. I didn't see this behaviour on my

Re: [uml-devel] [PATCH v3] um: Switch clocksource to hrtimers

Am 31.10.2015 um 16:10 schrieb Thomas Meyer: > Am Samstag, den 31.10.2015, 14:54 +0100 schrieb Richard Weinberger: >> On Thu, Oct 29, 2015 at 7:23 AM, Anton Ivanov >> wrote: >>> I got the first patchset to build, it works very well on a single >>> core >>> host or

Re: [uml-devel] [PATCH v3] um: Switch clocksource to hrtimers

Am 31.10.2015 um 16:16 schrieb Thomas Meyer: > mhh. strange. I didn't see this behaviour on my machine, but my machine > is a rare single core system so, likely a race condition while relaying > the timer interrupt to the userspace process. Here I can trigger it by starting UML, logging in and

Re: [uml-devel] [PATCH v3] um: Switch clocksource to hrtimers

Am Samstag, den 31.10.2015, 14:54 +0100 schrieb Richard Weinberger: > On Thu, Oct 29, 2015 at 7:23 AM, Anton Ivanov > wrote: > > I got the first patchset to build, it works very well on a single > > core > > host or with CPU pinning of the UML - the performance

Re: [uml-devel] [PATCH v3] um: Switch clocksource to hrtimers

Richard, can you send me your config. I have had it running for a couple of days before submission both under load and idle it was doing OK. A On 31/10/15 15:44, Thomas Meyer wrote: > Am Samstag, den 31.10.2015, 16:30 +0100 schrieb Richard Weinberger: >> Am 31.10.2015 um 16:24 schrieb Thomas

Re: [uml-devel] [PATCH v3] um: Switch clocksource to hrtimers

I got the first patchset to build, it works very well on a single core host or with CPU pinning of the UML - the performance gain is > 25%. However, I introduced a race somewhere along the way - it crashes UML reliably if you do not pin CPUs. I will debug it, fix it and submit. I am guessing a

Re: [uml-devel] [PATCH v3] um: Switch clocksource to hrtimers

Hi! Am 25.10.2015 um 19:46 schrieb Anton Ivanov: > Hi List, hi Richard, > > I am going to sort out the UBD patchset next as that has no dependencies on > timer and the other stuff which is waiting in the queue behind the timers. > > That should give UML a significant boost. It is nothing

Re: [uml-devel] [PATCH v3] um: Switch clocksource to hrtimers

Hi List, hi Richard, I am going to sort out the UBD patchset next as that has no dependencies on timer and the other stuff which is waiting in the queue behind the timers. That should give UML a significant boost. It is nothing particularly revolutionary (qemu has been using some of that for

[uml-devel] [PATCH v3] um: Switch clocksource to hrtimers

Background: UML is using an obsolete itimer call for all timers and "polls" for kernel space timer firing in its userspace portion resulting in a long list of bugs and incorrect behaviour(s). It also uses ITIMER_VIRTUAL for its timer which results in the timer being dependent on it running and the

Re: [uml-devel] [PATCH v3] um: Print minimum physical memory requirement

On Fri, Apr 3, 2015 at 4:51 PM, Thomas Meyer tho...@m3y3r.de wrote: Print a more sensible message about the minimum physical memory requirement. Signed-off-by: Thomas Meyer tho...@m3y3r.de All of your three patches are queued for 4.1! :-) -- Thanks, //richard

Re: [uml-devel] [PATCH v3] um: Print minimum physical memory requirement

Thanks Richard :-) With kind regards Thomas Am 13.04.2015 um 21:23 schrieb Richard Weinberger richard.weinber...@gmail.com: On Fri, Apr 3, 2015 at 4:51 PM, Thomas Meyer tho...@m3y3r.de wrote: Print a more sensible message about the minimum physical memory requirement. Signed-off-by:

[uml-devel] [PATCH v3] um: Print minimum physical memory requirement

Print a more sensible message about the minimum physical memory requirement. Signed-off-by: Thomas Meyer tho...@m3y3r.de --- diff --git a/arch/um/kernel/physmem.c b/arch/um/kernel/physmem.c index 549ecf3..6f20626 100644 --- a/arch/um/kernel/physmem.c +++ b/arch/um/kernel/physmem.c @@ -57,22

Re: [uml-devel] [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap

On Thu, 2015-03-26 at 10:43 +0100, Ingo Molnar wrote: * Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Wed, 2015-03-25 at 19:36 +0100, Ingo Molnar wrote: * Ingo Molnar mi...@kernel.org wrote: +#define __HAVE_ARCH_REMAP +static inline void arch_remap(struct

Re: [uml-devel] [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap

On 26/03/2015 15:17, Ingo Molnar wrote: * Laurent Dufour lduf...@linux.vnet.ibm.com 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

Re: [uml-devel] [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap

On 26/03/2015 10:43, Ingo Molnar wrote: * Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Wed, 2015-03-25 at 19:36 +0100, Ingo Molnar wrote: * Ingo Molnar mi...@kernel.org wrote: +#define __HAVE_ARCH_REMAP +static inline void arch_remap(struct mm_struct *mm, +

Re: [uml-devel] [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap

* Ingo Molnar mi...@kernel.org 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) +{ + /* +*

Re: [uml-devel] [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap

On 26/03/2015 10:48, Ingo Molnar wrote: * Benjamin Herrenschmidt b...@kernel.crashing.org wrote: +#define __HAVE_ARCH_REMAP +static inline void arch_remap(struct mm_struct *mm, +unsigned long old_start, unsigned long old_end, +unsigned long

Re: [uml-devel] [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap

* Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Wed, 2015-03-25 at 19:36 +0100, Ingo Molnar wrote: * Ingo Molnar mi...@kernel.org wrote: +#define __HAVE_ARCH_REMAP +static inline void arch_remap(struct mm_struct *mm, + unsigned long

Re: [uml-devel] [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap

On Wed, 2015-03-25 at 19:36 +0100, Ingo Molnar wrote: * Ingo Molnar mi...@kernel.org wrote: +#define __HAVE_ARCH_REMAP +static inline void arch_remap(struct mm_struct *mm, + unsigned long old_start, unsigned long old_end, + unsigned long

Re: [uml-devel] [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap

* Benjamin Herrenschmidt b...@kernel.crashing.org 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)

Re: [uml-devel] [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap

* Laurent Dufour lduf...@linux.vnet.ibm.com 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) +

Re: [uml-devel] [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap

On Wed, 2015-03-25 at 19:33 +0100, Ingo Molnar wrote: * Laurent Dufour lduf...@linux.vnet.ibm.com wrote: +static inline void arch_unmap(struct mm_struct *mm, + struct vm_area_struct *vma, + unsigned long start, unsigned long end) +{ + if (start =

Re: [uml-devel] [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap

* Laurent Dufour lduf...@linux.vnet.ibm.com 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

[uml-devel] [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap

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. This patch handles vDSO

[uml-devel] [PATCH v3 0/2] Tracking user space vDSO remaping

CRIU is recreating the process memory layout by remapping the checkpointee memory area on top of the current process (criu). This includes remapping the vDSO to the place it has at checkpoint time. However some architectures like powerpc are keeping a reference to the vDSO base address to build

[uml-devel] [PATCH v3 1/2] mm: Introducing arch_remap hook

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_unmap hook is called). The architectures

Re: [uml-devel] [PATCH v3 3/3] um: enable trace irqflags support

On Sun, Oct 19, 2014 at 5:14 PM, Thomas Meyer tho...@m3y3r.de wrote: --- a/arch/um/kernel/um_arch.c +++ b/arch/um/kernel/um_arch.c @@ -251,6 +251,9 @@ static struct notifier_block panic_exit_notifier = { void uml_finishsetup(void) { +#ifdef CONFIG_LOCKDEP + lockdep_init(); +#endif

Re: [uml-devel] [PATCH v3 3/3] um: enable trace irqflags support

- Original Message - From: Thomas Meyer tho...@m3y3r.de To: user-mode-linux-devel user-mode-linux-devel@lists.sourceforge.net Sent: Sunday, October 19, 2014 4:14:13 PM Subject: [uml-devel] [PATCH v3 3/3] um: enable trace irqflags support Add TRACE_IRQFLAGS_SUPPORT to UML

Re: [uml-devel] [PATCH v3 3/3] um: enable trace irqflags support

Am 20.10.2014 11:28 schrieb Daniel Walter sa...@0x90.at: - Original Message - From: Thomas Meyer tho...@m3y3r.de To: user-mode-linux-devel user-mode-linux-devel@lists.sourceforge.net Sent: Sunday, October 19, 2014 4:14:13 PM Subject: [uml-devel] [PATCH v3 3/3] um: enable

Re: [uml-devel] [PATCH v3 3/3] um: enable trace irqflags support

, 2014 4:14:13 PM Subject: [uml-devel] [PATCH v3 3/3] um: enable trace irqflags support Add TRACE_IRQFLAGS_SUPPORT to UML. This enables LOCKDEP_SUPPORT and TRACING_SUPPORT. FYI: I'm currently working on porting ftrace() support to uml. It will take another week or two since I don't have

Re: [uml-devel] [PATCH v3 3/3] um: enable trace irqflags support

@lists.sourceforge.net Sent: Sunday, October 19, 2014 4:14:13 PM Subject: [uml-devel] [PATCH v3 3/3] um: enable trace irqflags support Add TRACE_IRQFLAGS_SUPPORT to UML. This enables LOCKDEP_SUPPORT and TRACING_SUPPORT. FYI: I'm currently working on porting ftrace() support to uml

[uml-devel] [PATCH v3 2/3] um: add a kmsg_dumper

Add a kmsg_dumper, that dumps the kmsg buffer to stdout, when no console is available. This an enables the printing of early panic() calls triggered in uml_postsetup(). Signed-off-by: Thomas Meyer tho...@m3y3r.de --- diff -r ee0ba83fd81e arch/um/kernel/Makefile --- a/arch/um/kernel/Makefile

[uml-devel] [PATCH v3 3/3] um: enable trace irqflags support

Add TRACE_IRQFLAGS_SUPPORT to UML. This enables LOCKDEP_SUPPORT and TRACING_SUPPORT. Signed-off-by: Thomas Meyer tho...@m3y3r.de --- diff --git a/arch/um/Kconfig.common b/arch/um/Kconfig.common index 87bc868..6a33c3a 100644 --- a/arch/um/Kconfig.common +++ b/arch/um/Kconfig.common @@ -28,10 +28,9

[uml-devel] [PATCH v3 1/3] um: Move uml_postsetup in the init_thread stack

atomic_notifier_chain_register() and uml_postsetup() do call kernel code that rely on the current macro and a valid task_struct resp. thread_info struct. Signed-off-by: Thomas Meyer tho...@m3y3r.de --- diff --git a/arch/um/include/shared/as-layout.h b/arch/um/include/shared/as-layout.h index

[uml-devel] [PATCH v3 06/10] RAW Ethernet transport for UML

From: Anton Ivanov antiv...@cisco.com This is an alternative to the well known pcap transport. In the absense of special hardware support pcap is slow, guaranteed to be slow and with significant penalties on NUMA/SMP systems due to the timestamping of every packet. This transport does not incur

[uml-devel] [PATCH v3 02/10] Remove unnecessary 'reactivate' statements

From: Anton Ivanov antiv...@cisco.com The epoll based controller has real (not emulated) edge and level semantics and the edge/level is handled by epoll. There is no toggling of the poll set any more, thus it is removed throughout Signed-off-by: Anton Ivanov antiv...@cisco.com ---

[uml-devel] [PATCH v3 08/10] Minor performance optimization for ubd

From: Anton Ivanov antiv...@cisco.com Obvious performance optimization - it is not necessary to read the requests one at a time in the IRQ handler Signed-off-by: Anton Ivanov antiv...@cisco.com --- arch/um/drivers/ubd_kern.c | 29 ++--- 1 file changed, 22

[uml-devel] [PATCH v3 07/10] Performance and NUMA improvements for ubd

From: Anton Ivanov antiv...@cisco.com The use of the seek()/read() and seek()/write() is a terminal disease on NUMA. Intense use of this on shared files (f.e. the master for a COW image) can cause anything up to and including killing CPUs on unhandled NMIs. This patch deals with this UML major

[uml-devel] [PATCH v3 05/10] GRE transport for UML

From: Anton Ivanov antiv...@cisco.com This transport allows a UML to connect to another UML local or remote, the Linux host or any other network device running the industry standard Ethernet over GRE protocol. The transport supports all features of RFC 2784. The transport supports a common set

[uml-devel] [PATCH v3 04/10] L2TPv3 Transport Driver for UML

From: Anton Ivanov antiv...@cisco.com This transport allows a UML to connect to another UML local or remote, the Linux host or any other network device running the industry standard Ethernet over L2TPv3 protocol as per RFC 3931 (and successors). The transport supports a common set of features

[uml-devel] [PATCH v3 01/10] Epoll based interrupt controller

From: Anton Ivanov antiv...@cisco.com 1. Minimum kernel 2.5.99 2. No walk the list lookups for received IRQs - immediate identification of the correct handler to invoke 3. Full set of IRQ semantics - edge, level, read, write 3.1. Write is now a *REAL* write - so if you (ab)use the write

[uml-devel] [PATCH v3 09/10] Better IPC for UBD

From: Anton Ivanov antiv...@cisco.com socketpair() is a better IPC choice for lots of small requests as it allows deeper (and configurable) queues than pipe() As a result UBD will process nearly all of the requests submitted to it instead of bouncing a significant percentage under load

[uml-devel] [PATCH v3 03/10] High performance networking subsystem

From: Anton Ivanov antiv...@cisco.com Support for multi-packet vector IO - multiple packets read in one syscall and (optionally) written in one syscall. Support for (optional) queueing on EAGAIN/ENOBUFS - applies only to socket transports. Sorry TAP, -EYOULOSE - it will remain

[uml-devel] [PATCH v3 10/10] High Resolution Timer subsystem for UML

From: Anton Ivanov antiv...@cisco.com This patch adds an extra timer source which has correct timing and uses an up-to-date OS API and. Results - correct kernel behaviour on timer related tasks. 1. Improvement in network performance (TCP state machines are now fed correct time). 2.

Re: [uml-devel] [PATCH v3] arch: Kconfig: Let all architectures set endian explicitly

Hello all: It seems no any additional rejections for it. I guess, I need split the 'big' patch into pieces, and each send to its' related mailing list, so let it not like a spam. And the schedule may like: - Firstly, send patch for init/Kconfig to add CPU_*_ENDIAN. If pass checking (hope it

Re: [uml-devel] [PATCH v3] arch: Kconfig: Let all architectures set endian explicitly

Hello Maintainers: Is this patch OK? If it pass basic checking, please let me know, and I shall try to make another related patch for KBuild (I can do nothing related with Kbuild, before get confirmation for this patch). Thanks. On 8/15/14 17:01, Chen Gang wrote: On 8/15/14 6:14, Chen Gang

Re: [uml-devel] [PATCH v3] arch: Kconfig: Let all architectures set endian explicitly

On 8/15/14 6:14, Chen Gang wrote: On 08/15/2014 02:04 AM, Ralf Baechle wrote: OK, thanks, I assumes when support both endian, the default choice is CPU_BIG_ENDIAN, although no default value for choice (originally, I did worry about it). So I think you can just drop the MIPS segment

Re: [uml-devel] [PATCH v3] arch: Kconfig: Let all architectures set endian explicitly

On 08/15/2014 02:27 AM, Lennox Wu wrote: I don't think it's necessary, what's the benfit? 2014-08-15 2:21 GMT+08:00 Vineet Gupta vineet.gup...@synopsys.com: On Thursday 14 August 2014 09:55 AM, Chen Gang wrote: [...] diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig index 9596b0a..e939abd

Re: [uml-devel] [PATCH v3] arch: Kconfig: Let all architectures set endian explicitly

On Thursday 14 August 2014 03:22 PM, Chen Gang wrote: For many individual modules may need check CPU_LITTLE_ENDIAN or CPU_BIG_ENDIAN, which is an architecture's attribute. Or they have to list many architectures which they support, which they don't support. And still, it is not precise. For

Re: [uml-devel] [PATCH v3] arch: Kconfig: Let all architectures set endian explicitly

On Thursday 14 August 2014 09:55 AM, Chen Gang wrote: Normal architectures: - Big endian: avr32, frv, m68k, openrisc, parisc, s390, sparc - Little endian: alpha, blackfin, cris, hexagon, ia64, metag, mn10300, score, unicore32, x86 - Choose in config time: arc, arm,

Re: [uml-devel] [PATCH v3] arch: Kconfig: Let all architectures set endian explicitly

On 08/15/2014 02:04 AM, Ralf Baechle wrote: On Fri, Aug 15, 2014 at 12:54:53AM +0800, Chen Gang wrote: Normal architectures: - Big endian: avr32, frv, m68k, openrisc, parisc, s390, sparc - Little endian: alpha, blackfin, cris, hexagon, ia64, metag, mn10300, score,

Re: [uml-devel] [PATCH v3] arch: Kconfig: Let all architectures set endian explicitly

On 8/15/14 7:12, Vineet Gupta wrote: On Thursday 14 August 2014 03:22 PM, Chen Gang wrote: For many individual modules may need check CPU_LITTLE_ENDIAN or CPU_BIG_ENDIAN, which is an architecture's attribute. Or they have to list many architectures which they support, which they don't

Re: [uml-devel] [PATCH v3] arch: Kconfig: Let all architectures set endian explicitly

On Fri, Aug 15, 2014 at 12:54:53AM +0800, Chen Gang wrote: Normal architectures: - Big endian: avr32, frv, m68k, openrisc, parisc, s390, sparc - Little endian: alpha, blackfin, cris, hexagon, ia64, metag, mn10300, score, unicore32, x86 - Choose in config time: arc,

Re: [uml-devel] [PATCH v3] arch: Kconfig: Let all architectures set endian explicitly

I don't think it's necessary, what's the benfit? 2014-08-15 2:21 GMT+08:00 Vineet Gupta vineet.gup...@synopsys.com: On Thursday 14 August 2014 09:55 AM, Chen Gang wrote: Normal architectures: - Big endian: avr32, frv, m68k, openrisc, parisc, s390, sparc - Little endian: alpha,

[uml-devel] [PATCH v3] arch: Kconfig: Let all architectures set endian explicitly

Normal architectures: - Big endian: avr32, frv, m68k, openrisc, parisc, s390, sparc - Little endian: alpha, blackfin, cris, hexagon, ia64, metag, mn10300, score, unicore32, x86 - Choose in config time: arc, arm, arm64, c6x, m32r, mips, powerpc, sh Special architectures:

Re: [uml-devel] [PATCH v3] arch: Kconfig: Let all architectures set endian explicitly

Hi Chen, On Thu, Aug 14, 2014 at 8:54 PM, Chen Gang gang.chen.5...@gmail.com wrote: Normal architectures: - Big endian: avr32, frv, m68k, openrisc, parisc, s390, sparc - Little endian: alpha, blackfin, cris, hexagon, ia64, metag, mn10300, score, unicore32, x86 -

Re: [uml-devel] [PATCH v3] arch: Kconfig: Let all architectures set endian explicitly

On 8/15/14 9:52, Max Filippov wrote: On Fri, Aug 15, 2014 at 5:47 AM, Max Filippov jcmvb...@gmail.com wrote: Hi Chen, On Thu, Aug 14, 2014 at 8:54 PM, Chen Gang gang.chen.5...@gmail.com wrote: Normal architectures: - Big endian: avr32, frv, m68k, openrisc, parisc, s390, sparc - Little

Re: [uml-devel] [PATCH v3] arch: Kconfig: Let all architectures set endian explicitly

On Fri, Aug 15, 2014 at 5:47 AM, Max Filippov jcmvb...@gmail.com wrote: Hi Chen, On Thu, Aug 14, 2014 at 8:54 PM, Chen Gang gang.chen.5...@gmail.com wrote: Normal architectures: - Big endian: avr32, frv, m68k, openrisc, parisc, s390, sparc - Little endian: alpha, blackfin, cris, hexagon,

Re: [uml-devel] [PATCH v3] arm64, ia64, ppc, s390, sh, tile, um, x86, mm: Remove default gate area

On 07/18/2014 11:53 AM, Andy Lutomirski wrote: On Jul 18, 2014 3:20 AM, Richard Weinberger rich...@nod.at mailto:rich...@nod.at wrote: Am 18.07.2014 12:14, schrieb Will Deacon: On Tue, Jul 15, 2014 at 03:47:26PM +0100, Andy Lutomirski wrote: On Sun, Jul 13, 2014 at 1:01 PM, Andy

Re: [uml-devel] [PATCH v3] arm64, ia64, ppc, s390, sh, tile, um, x86, mm: Remove default gate area

On Tue, Jul 15, 2014 at 03:47:26PM +0100, Andy Lutomirski wrote: On Sun, Jul 13, 2014 at 1:01 PM, Andy Lutomirski l...@amacapital.net wrote: The core mm code will provide a default gate area based on FIXADDR_USER_START and FIXADDR_USER_END if !defined(__HAVE_ARCH_GATE_AREA)

Re: [uml-devel] [PATCH v3] arm64, ia64, ppc, s390, sh, tile, um, x86, mm: Remove default gate area

On Jul 18, 2014 3:20 AM, Richard Weinberger rich...@nod.at wrote: Am 18.07.2014 12:14, schrieb Will Deacon: On Tue, Jul 15, 2014 at 03:47:26PM +0100, Andy Lutomirski wrote: On Sun, Jul 13, 2014 at 1:01 PM, Andy Lutomirski l...@amacapital.net wrote: The core mm code will provide a default

Re: [uml-devel] [PATCH v3] arm64, ia64, ppc, s390, sh, tile, um, x86, mm: Remove default gate area

On Sun, Jul 13, 2014 at 1:01 PM, Andy Lutomirski l...@amacapital.net wrote: The core mm code will provide a default gate area based on FIXADDR_USER_START and FIXADDR_USER_END if !defined(__HAVE_ARCH_GATE_AREA) defined(AT_SYSINFO_EHDR). This default is only useful for ia64. arm64, ppc, s390,

[uml-devel] [PATCH v3] arm64, ia64, ppc, s390, sh, tile, um, x86, mm: Remove default gate area

The core mm code will provide a default gate area based on FIXADDR_USER_START and FIXADDR_USER_END if !defined(__HAVE_ARCH_GATE_AREA) defined(AT_SYSINFO_EHDR). This default is only useful for ia64. arm64, ppc, s390, sh, tile, 64-bit UML, and x86_32 have their own code just to disable it. arm,

  1   2   >