Re: Kernel 4.7rc3 - Performance drop 30-40% for SPECjbb2005 and SPECjvm2008 benchmarks against 4.6 kernel

Could it be related to this: https://www.phoronix.com/scan.php?page=news_item=P-State-Possible-4.6-Regression On Thu, 16 Jun 2016 18:40:01 +0200 Jirka Hladky wrote: > Hello, > > we see performance drop 30-40% for SPECjbb2005 and SPECjvm2008 > benchmarks starting from

Re: Kernel 4.7rc3 - Performance drop 30-40% for SPECjbb2005 and SPECjvm2008 benchmarks against 4.6 kernel

Could it be related to this: https://www.phoronix.com/scan.php?page=news_item=P-State-Possible-4.6-Regression On Thu, 16 Jun 2016 18:40:01 +0200 Jirka Hladky wrote: > Hello, > > we see performance drop 30-40% for SPECjbb2005 and SPECjvm2008 > benchmarks starting from 4.7.0-0.rc0 kernel

btrf stuck in iowait with latest git

Last night I have pulled and installed latest kernel and immediateley noticed that git pull on btrfs file system is stuck. Io wait was high without noticing that there is something to wait for. Also noticed that btrfs_transactio process was stuck with 'D'. Tryed sync and that also got stuck. I

btrf stuck in iowait with latest git

Last night I have pulled and installed latest kernel and immediateley noticed that git pull on btrfs file system is stuck. Io wait was high without noticing that there is something to wait for. Also noticed that btrfs_transactio process was stuck with 'D'. Tryed sync and that also got stuck. I

oops when swapping on latest kernel git 3.15-rc5

Ia hev discovered this accidentaly when tried to see how oom killer works. Program is this: #include #include #include #include int counter=0; int main() try { for(;;++counter) { char* p = new char[1024*1024]; memset(p,1,1024*1024); std::cout< 24000)sleep(100); }

oops when swapping on latest kernel git 3.15-rc5

Ia hev discovered this accidentaly when tried to see how oom killer works. Program is this: #include unistd.h #include cstring #include exception #include iostream int counter=0; int main() try { for(;;++counter) { char* p = new char[1024*1024]; memset(p,1,1024*1024);

15995MB available under Linux but 16329MB available under Win 7

This really puzzles me. bmaxa@maxa:~$ lspci -v -s 01:00.0 01:00.0 VGA compatible controller: NVIDIA Corporation GF114 [GeForce GTX 560 Ti] (rev a1) (prog-if 00 [VGA controller]) Subsystem: CardExpert Technology Device 0801 Flags: bus master, fast devsel, latency 0, IRQ 52 Memory at

15995MB available under Linux but 16329MB available under Win 7

This really puzzles me. bmaxa@maxa:~$ lspci -v -s 01:00.0 01:00.0 VGA compatible controller: NVIDIA Corporation GF114 [GeForce GTX 560 Ti] (rev a1) (prog-if 00 [VGA controller]) Subsystem: CardExpert Technology Device 0801 Flags: bus master, fast devsel, latency 0, IRQ 52 Memory at

Re: latest git usb3.0 ports not working

On 01/29/2014 11:11 PM, Sarah Sharp wrote: On Tue, Jan 21, 2014 at 02:17:06PM -0800, Sarah Sharp wrote: On Tue, Jan 21, 2014 at 07:47:22PM +0100, Branimir Maksimovic wrote: asus maximus v gene motherboard, this is from dmesg: [ 75.576160] xhci_hcd :03:00.0: Timeout while waiting

Re: latest git usb3.0 ports not working

On 01/29/2014 11:11 PM, Sarah Sharp wrote: On Tue, Jan 21, 2014 at 02:17:06PM -0800, Sarah Sharp wrote: On Tue, Jan 21, 2014 at 07:47:22PM +0100, Branimir Maksimovic wrote: asus maximus v gene motherboard, this is from dmesg: [ 75.576160] xhci_hcd :03:00.0: Timeout while waiting

latest git usb3.0 ports not working

asus maximus v gene motherboard, this is from dmesg: [ 75.576160] xhci_hcd :03:00.0: Timeout while waiting for a slot [ 88.991634] xhci_hcd :03:00.0: Stopped the command ring failed, maybe the host is dead [ 88.991748] xhci_hcd :03:00.0: Abort command ring failed [

latest git usb3.0 ports not working

asus maximus v gene motherboard, this is from dmesg: [ 75.576160] xhci_hcd :03:00.0: Timeout while waiting for a slot [ 88.991634] xhci_hcd :03:00.0: Stopped the command ring failed, maybe the host is dead [ 88.991748] xhci_hcd :03:00.0: Abort command ring failed [

Re: Poor network performance x86_64.. also with 3.13

On 01/20/2014 11:37 PM, Borislav Petkov wrote: On Mon, Jan 20, 2014 at 11:27:25PM +0100, Daniel Exner wrote: I just did the same procedure with Kernel Version 3.13: same poor rates. I think I will try to see of 3.12.6 was still ok and bisect from there. Or try something more coarse-grained

Re: Poor network performance x86_64.. also with 3.13

On 01/20/2014 11:37 PM, Borislav Petkov wrote: On Mon, Jan 20, 2014 at 11:27:25PM +0100, Daniel Exner wrote: I just did the same procedure with Kernel Version 3.13: same poor rates. I think I will try to see of 3.12.6 was still ok and bisect from there. Or try something more coarse-grained

Re: vm commit in atop utility steadilly grows (latest mainline kernel from git)

On 01/18/2014 09:34 AM, Andrew Morton wrote: On Fri, 17 Jan 2014 20:06:21 +0100 Branimir Maksimovic wrote: Yesterday, I have noticed that vmcom steadilly grows (it was 7TB before I noticed). I compile kernel every day or two after git pull. Rebooted and then watched atop, vmcom constantly

Re: vm commit in atop utility steadilly grows (latest mainline kernel from git)

Hm, I don't know what happened, perhaps I miscompiled but after todays git updates and recompile problem is no more. On 01/17/2014 08:06 PM, Branimir Maksimovic wrote: Yesterday, I have noticed that vmcom steadilly grows (it was 7TB before I noticed). I compile kernel every day or two after git

Re: vm commit in atop utility steadilly grows (latest mainline kernel from git)

Hm, I don't know what happened, perhaps I miscompiled but after todays git updates and recompile problem is no more. On 01/17/2014 08:06 PM, Branimir Maksimovic wrote: Yesterday, I have noticed that vmcom steadilly grows (it was 7TB before I noticed). I compile kernel every day or two after git

Re: vm commit in atop utility steadilly grows (latest mainline kernel from git)

On 01/18/2014 09:34 AM, Andrew Morton wrote: On Fri, 17 Jan 2014 20:06:21 +0100 Branimir Maksimovic branimir.maksimo...@gmail.com wrote: Yesterday, I have noticed that vmcom steadilly grows (it was 7TB before I noticed). I compile kernel every day or two after git pull. Rebooted

vm commit in atop utility steadilly grows (latest mainline kernel from git)

Yesterday, I have noticed that vmcom steadilly grows (it was 7TB before I noticed). I compile kernel every day or two after git pull. Rebooted and then watched atop, vmcom constantly grows. Didn't notice any of running processes to allocate. Booted in 3.12.8 kernel and everything is back to

vm commit in atop utility steadilly grows (latest mainline kernel from git)

Yesterday, I have noticed that vmcom steadilly grows (it was 7TB before I noticed). I compile kernel every day or two after git pull. Rebooted and then watched atop, vmcom constantly grows. Didn't notice any of running processes to allocate. Booted in 3.12.8 kernel and everything is back to