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,
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
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 transports as well support
for direct w
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 of
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 NIC
use case by up to 10%.
4. Intr
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 output to stderr
> by ad
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 o
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 io_thr
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 performance improvement i
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 will hit next tomorro
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
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 w
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
PTRACE_GETFPR
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 -
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
---
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 program
Acked-by: Tristan Schmelcher
--
___
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-d
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 cal
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 na
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 thi
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.
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 ru
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.
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.
>>>
>>> What do you use for userspace (so I can try to repro
[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 a
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 (
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 multicore).
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 c
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 con
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 the
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 c
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
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 nanoslee
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. str
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 Me
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 machi
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 condi
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
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 wai
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 the first patchset to build, it
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 with CPU pinning of the UML - the
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 gain is >
> > 25%.
> >
> > However,
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 crashes UML
> reliably if you do not pi
On Thu, 2015-10-29 at 14:46 +0530, Saurabh Sengar wrote:
> replace GFP_KERNEL with GFP_ATOMIC while spinlock is held,
> as code while holding a spinlock should be atomic.
> GFP_KERNEL may sleep and can cause deadlock,
> where as GFP_ATOMIC may fail but certainly avoids deadlock
>
> Signed-off-by:
Am 29.10.2015 um 15:50 schrieb Joe Perches:
> On Thu, 2015-10-29 at 14:46 +0530, Saurabh Sengar wrote:
>> replace GFP_KERNEL with GFP_ATOMIC while spinlock is held,
>> as code while holding a spinlock should be atomic.
>> GFP_KERNEL may sleep and can cause deadlock,
>> where as GFP_ATOMIC may fail
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
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 partic
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 a
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
Thanks Richard :-)
With kind regards
Thomas
> Am 13.04.2015 um 21:23 schrieb Richard Weinberger
> :
>
>> On Fri, Apr 3, 2015 at 4:51 PM, Thomas Meyer wrote:
>> Print a more sensible message about the minimum physical memory
>> requirement.
>>
>> Signed-off-by: Thomas Meyer
>
> All of your t
On Fri, Apr 3, 2015 at 4:51 PM, Thomas Meyer wrote:
> Print a more sensible message about the minimum physical memory
> requirement.
>
> Signed-off-by: Thomas Meyer
All of your three patches are queued for 4.1! :-)
--
Thanks,
//richard
-
Thomas Meyer wrote:
>+ printf("Too few physical memory! Needed=%d, given=%d\n",
I think 'Too little physical memory' would be more correct. Or maybe
'Insufficient physical memory'.
Ron
--
Dive into the Worl
Print a more sensible message about the minimum physical memory
requirement.
Signed-off-by: Thomas Meyer
---
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 +57,51 @@ void map_me
On 26/03/2015 15:17, Ingo Molnar wrote:
>
> * 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, o
On Thu, 2015-03-26 at 10:43 +0100, Ingo Molnar wrote:
> * 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:
> > 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
On Wed, 2015-03-25 at 19:33 +0100, Ingo Molnar wrote:
> * 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.vd
On 26/03/2015 10:48, Ingo Molnar wrote:
>
> * 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_st
* 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)
> > > +{
> > > +
On 26/03/2015 10:43, Ingo Molnar wrote:
>
> * 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,
> + unsigned
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,
> > > + unsigned long old_start, unsigned long old_end,
> > > + unsigned long new_
* 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_start, unsigned long new_end)
> > +{
> > + /*
> > +* mr
* 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,
> > > > + unsigned long old_start, unsigned long
> >
* 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
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 w
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 th
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 remappin
pm_power_off is defined for all architectures. Move it to common code.
Have all architectures call do_kernel_power_off instead of pm_power_off.
Some architectures point pm_power_off to machine_power_off. For those,
call do_kernel_power_off from machine_power_off instead.
Acked-by: David Vrabel
A
ser-mode-linux-devel"
>>>> 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 TRACI
On Mon, Oct 20, 2014 at 1:18 PM, Thomas Meyer wrote:
> Am 20.10.2014 11:28 schrieb Daniel Walter :
>>
>> - Original Message -
>> > From: "Thomas Meyer"
>> > To: "user-mode-linux-devel"
>> > Sent: Sunday, October 19, 2014
Am 20.10.2014 11:28 schrieb Daniel Walter :
>
> - Original Message -
> > From: "Thomas Meyer"
> > To: "user-mode-linux-devel"
> > Sent: Sunday, October 19, 2014 4:14:13 PM
> > Subject: [uml-devel] [PATCH v3 3/3] um: enable trace irq
- Original Message -
> From: "Thomas Meyer"
> To: "user-mode-linux-devel"
> 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 L
On Sun, Oct 19, 2014 at 5:14 PM, Thomas Meyer 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
The #
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
---
diff --git a/arch/um/include/shared/as-layout.h
b/arch/um/include/shared/as-layout.h
index 41c8c77..ca1843e
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
---
diff -r ee0ba83fd81e arch/um/kernel/Makefile
--- a/arch/um/kernel/Makefile Sat Oct 11 18:55:
Add TRACE_IRQFLAGS_SUPPORT to UML.
This enables LOCKDEP_SUPPORT and TRACING_SUPPORT.
Signed-off-by: Thomas Meyer
---
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 @@ config PCI
From: Anton Ivanov
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. Correct QoS and traffic
From: Anton Ivanov
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
Signed-off-by: Anton Ivanov
From: Anton Ivanov
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 to signify NONE (a
From: Anton Ivanov
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
slower than any so
From: Anton Ivanov
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 with the kernel
imple
From: Anton Ivanov
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 issue (and one of UM
From: Anton Ivanov
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 of features with the
From: Anton Ivanov
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
---
arch/um/drivers/chan_kern.c |2 --
arch/um
From: Anton Ivanov
Obvious performance optimization - it is not necessary
to read the requests one at a time in the IRQ handler
Signed-off-by: Anton Ivanov
---
arch/um/drivers/ubd_kern.c | 29 ++---
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/arch/u
From: Anton Ivanov
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 any of these times
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
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 Ga
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 se
On Fri, Aug 15, 2014 at 5:47 AM, Max Filippov wrote:
> Hi Chen,
>
> On Thu, Aug 14, 2014 at 8:54 PM, Chen Gang wrote:
>> Normal architectures:
>>
>> - Big endian: avr32, frv, m68k, openrisc, parisc, s390, sparc
>>
>> - Little endian: alpha, blackfin, cris, hexagon, ia64, metag, mn10300,
>>
On 8/15/14 9:52, Max Filippov wrote:
> On Fri, Aug 15, 2014 at 5:47 AM, Max Filippov wrote:
>> Hi Chen,
>>
>> On Thu, Aug 14, 2014 at 8:54 PM, Chen Gang wrote:
>>> Normal architectures:
>>>
>>> - Big endian: avr32, frv, m68k, openrisc, parisc, s390, sparc
>>>
>>> - Little endian: alpha, blackfi
Hi Chen,
On Thu, Aug 14, 2014 at 8:54 PM, 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:
I don't think it's necessary, what's the benfit?
2014-08-15 2:21 GMT+08:00 Vineet Gupta :
> 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, he
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:
-
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
>>
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, a
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,
>>
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 tim
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 :
>
>> On Thursday 14 August 2014 09:55 AM, Chen Gang wrote:
[...]
>>> diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
>>> index 9596b0a..e939abd 100644
>>> ---
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.
>
1 - 100 of 115 matches
Mail list logo
