Skip to content
Snippets Groups Projects
Select Git revision
  • simonci
  • vanillaCI
  • ibr/cpu-event-worker-leanstore-integration
  • ibr/cpu-event-worker
  • revert-dbd4f905
  • ibr/event-sched
  • job-queue
  • debug-shed-with-sclicing-and-multiple-cores
  • pr/sched-rr
  • ibr/sched-rr
  • dietrich/rwlock
  • dietrich/tcb-shrink
  • dietrich/memory-compression
  • master default protected
  • job-queue-load-balance
  • vldb24-vision
  • ipv6
  • riscv64
  • stable/v0.19
  • static-elf
  • v0.57.0
  • v0.56.0
  • v0.55.0
  • v0.54.0
  • v0.53.0
  • v0.52.0
  • v0.51.0
  • v0.24
  • v0.23
  • v0.22
  • v0.21
  • v0.20
  • v0.19
  • v0.18
  • v0.17
  • v0.16
  • v0.15
  • v0.15-rc3
  • v0.15-rc1
  • v0.14
40 results
Search by author
  • Any Author
  • Christian Dietrich Christian Dietrich dietrich
  • Niklas Gollenstede Niklas Gollenstede gollenst
  • Sebastian Kosak kosak
  • Simon-Nassim Kanoun kanoun
  • Sören Tempel Sören Tempel tempel
5 authors
  1. Dec 19, 2013
  3. Dec 18, 2013
  5. Dec 17, 2013
  7. Dec 16, 2013
  9. Dec 11, 2013
  11. Dec 09, 2013
  13. Dec 08, 2013
    • Glauber Costa's avatar
      xen: disable pvclock for more than 32 CPUs · 0ddd6ef1
      Glauber Costa authored 
      
Xen's shared info contains hardcoded space for only 32 CPUs.  Because we use
those structure to derive timing information, we would be basically accessing
random memory after that. This is very hard to test and trigger, so what I'd
did to demonstrate I was right (although that wasn't really needed, math could
be used for that...) was to print the first timing information a cpu would
produce. I could verify that the timing on CPUs > 32 was behind in time than
the time produced in CPUs < 32.

It is possible to move the vcpu area to a different location, but this is a
relatively new feature of the Xen Hypervisor: Amazon won't support it. So
we need a disable path anyway. I will open up an issue for somebody to implement
that support eventually.

Another user of the vcpu structure is interrupts. But for interrupts the story
is easier, since we can select which CPUs we can take interrupts at, and only
take them in the first 32 CPUs. In any case, we're taking them all in CPU0 now,
so already under control

Signed-off-by: default avatarGlauber Costa <glommer@cloudius-systems.com>
Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>
      0ddd6ef1
  15. Dec 06, 2013
    • Asias He's avatar
      virtio: Fix vring::used_ring_is_half_empty() calculation · c62c9dd8
      Asias He authored 
      
This patch fixes:

- The order of _used_ring_host_head and _used->_idx, the latter is more
  advanced than the former.
- The unwanted promotion to "int"

Pekka wrote:

   However, on the right-hand side, the expression type in master
   evaluates to "int" because of that innocent-looking constant "2" and
   lack of parenthesis after the cast.  That will also force the
   left-hand side to promote to "int".

   And no, I really don't claim to follow integer promotion rules so I
   used typeid().name() verify what the compiler is doing:

   [penberg@localhost tmp]$ cat types.cpp
   #include <typeinfo>
   #include <stdint.h>
   #include <cstdio>

   using namespace std;

   int main()
   {
       unsigned int _num = 1;

       printf("int                = %s\n", typeid(int).name());
       printf("uint16_t           = %s\n", typeid(uint16_t).name());
       printf("(uint16_t)_num/2)  = %s\n", typeid((uint16_t)_num/2).name());
       printf("(uint16_t)(_num/2) = %s\n", typeid((uint16_t)(_num/2)).name());
   }
   [penberg@localhost tmp]$ g++ -std=c++11 -Wall types.cpp
   [penberg@localhost tmp]$ ./a.out
   int                = i
   uint16_t           = t
   (uint16_t)_num/2)  = i
   (uint16_t)(_num/2) = t

Signed-off-by: default avatarAsias He <asias@cloudius-systems.com>
Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>
      c62c9dd8
    • Asias He's avatar
      virtio-net: Remove _tx_gc_lock lock · b92c33eb
      Asias He authored 
      
Now, the tx gc thread is gonna. The gc code can only be called in one
place. We do not need the lock anymore.

Signed-off-by: default avatarAsias He <asias@cloudius-systems.com>
Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>
      b92c33eb
    • Asias He's avatar
      virtio-net: Do _tx_queue->get_buf_gc() in virtio_net::tx_gc() · d41ccda8
      Asias He authored 
      
This unifies the code a bit: we do all the tx queue gc in one common
code path.

Signed-off-by: default avatarAsias He <asias@cloudius-systems.com>
Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>
      d41ccda8
    • Asias He's avatar
      virtio-net: Drop tx_gc_thread thread · 5b71c0f4
      Asias He authored 
      
We do tx queue gc on the tx path if there is not enough space. The tx
queue gc thread is not a must.

Dropping it saves us a running thread and saves a thread wakeup on every
interrupt.

Signed-off-by: default avatarAsias He <asias@cloudius-systems.com>
Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>
      5b71c0f4
    • Tomasz Grabiec's avatar
      virtio-blk: enable write caching · b2429878
      Tomasz Grabiec authored 
      
This is used by QEMU to determine if the guest will be using explicit
flush requests. If this is not enabled, it will flush using
fdatasync() after every write request.

This is causing dramatic performance degradation when using spinning
disk. This

The test "tests/tst-bdev-write.so" exposes the issue:

=== Before ===

0.469 Mb/s
0.312 Mb/s
0.323 Mb/s
0.354 Mb/s
0.163 Mb/s
0.100 Mb/s
0.388 Mb/s
0.293 Mb/s
0.401 Mb/s
Written 3.117 MB in 10.02 s

=== After ===

49.151 Mb/s
53.126 Mb/s
32.079 Mb/s
49.082 Mb/s
29.575 Mb/s
42.553 Mb/s
35.909 Mb/s
37.592 Mb/s
67.425 Mb/s
Written 440.562 MB in 10.00 s

Using "tests/tst-fs-stress.so":

=== Before ===

2.414 Mb/s
3.633 Mb/s
0.630 Mb/s
0.279 Mb/s
2.497 Mb/s
Written 15.379 MB in 10.51 s

Latency of write() [s]:
0     0.000000090
0.5   0.000004532
0.9   0.000005969
0.99  0.000022659
0.999 0.001138458
1.0   4.020670891

=== After ===

11.893 Mb/s
20.292 Mb/s
13.801 Mb/s
16.102 Mb/s
24.811 Mb/s
18.113 Mb/s
21.336 Mb/s
18.976 Mb/s
Written 182.254 MB in 10.00 s

Latency of write() [s]:
0     0.000000089
0.5   0.000004497
0.9   0.000005878
0.99  0.000018114
0.999 0.000111873
1.0   0.681828260

Signed-off-by: default avatarTomasz Grabiec <tgrabiec@cloudius-systems.com>
Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>
      b2429878
  17. Dec 05, 2013
  19. Dec 04, 2013