Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
ck-sources : All about choice !
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next  
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
thunderrd
n00b
n00b


Joined: 20 Aug 2010
Posts: 34

PostPosted: Mon Mar 25, 2013 2:27 pm    Post subject: Reply with quote

aCOSwt wrote:
Which fields of htop screen are you referring to ? Upper right load averages ? Upper left per cpu % ? %CPU column of the smp client ? / Which fields of top launched with which parameters ?

The CPU% column.

aCOSwt wrote:
Of course you know that, irrespective of your %CPU problem, this is wrong practice.

Err...yes. Maybe I wasn't clear enough when I said I'd configured the new kernel already, and it exhibited the problem, so I did this simply to localize the buggy behavior. It's what leads me to believe that the problem lies with BFS 428 and not the kernel itself; since I built 3.8.3 the second time with exactly the same options set, and its behavior is different from 3.6.11, that would appear to be the case. Of course it was only as a test. :)
Back to top
View user's profile Send private message
ryao
Developer
Developer


Joined: 27 Feb 2012
Posts: 118

PostPosted: Mon Mar 25, 2013 5:44 pm    Post subject: Reply with quote

aCOSwt wrote:
Following BUG 462190 and thanks to Markos Chandras, the ck-sources tree has been updated in order to :

- Push the 3.8.3 early release,

- Fix the deadlock regression in ZFS impacting on >= 3.6 kernels.

3.7 users can upgrade to 3.7.10-r1,
3.6 users can upgrade to 3.6.11-r2,

If they are using ZFS together with the Memory Resource Controller for Control Groups (CONFIG_MEMCG=y)

About the 3.8.3 early release, please note that :

- The upgradeable read/write locks optional patch has not been made available with this release.
- The full patchset no longer alters stock-Linux default settings of the dirty ratios. If you need advices on how to reset these as they used to be with < 3.8, just ask here.

Please also note that an always increasing number of security issues is being reported against 3.5.7 (See http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-6536 up to 2012-6549
We have no intention to provide security fixes for this branch => All 3.5 users should definitely upgrade to 3.4.34 / 3.6.11-r2 or 3.7.10-r1


ZFS is affected regardless of whether CONFIG_MEMCG is in effect or not. On the other hand, the patch that caused the regression is only useful when three conditions are met:

  1. CONFIG_MEMCG is enabled
  2. You are using memory cgroups
  3. You do heavy IO inside a memory cgroup that has a small memory limit.
I do not know of any deployed system that satisfies all 3 conditions.
Back to top
View user's profile Send private message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 5610
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Mon Mar 25, 2013 7:30 pm    Post subject: Reply with quote

aCOSwt wrote:
ulenrich wrote:
This urwlocks patch is also placed in the BFS ck1 for linux-3.8. But I think it has no meaning. grep urwlocks.h doesnt show any inclusion into the bfs patch?

Of course, it gets no meaning at all... alone !
As up to 3.7, it makes a little more sense when considered together with the bfs426-grq_urwlocks.patch...


here's an updated patch:

http://pastebin.com/cpqdXZye



currently re-compiling my kernel & will try it with a reboot later


any differences and/or improvements you guys noticed with urwlocks in the past ?

edit:

http://ck-hack.blogspot.co.at/2012/06/upgradeable-rwlocks-and-bfs.html?showComment=1339530561532#c3786277741482055329


edit.
_________________
Unofficial minimal livecd x86/amd64 w/reiser4+truecrypt (by Neo2)
2.6.37.2_plus_v1: BFS, CFS,THP,compaction, zcache or TOI
Hardcore Linux user since 2004 :D
Back to top
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2375
Location: Hilbert space

PostPosted: Mon Mar 25, 2013 8:01 pm    Post subject: Reply with quote

kernelOfTruth wrote:
here's an updated patch: http://pastebin.com/cpqdXZye

Thank you but... warning !
I submitted a patch to Con a couple of weeks ago that looks like... nearly exactly the same as yours...
(We have certainly built it almost the same way)
But Con... did not commit it in his repo so... Might have not been pleased with ?
kernelOfTruth wrote:
any differences and/or improvements you guys noticed with urwlocks in the past ?

Yes, the sysbench --test=threads test reports figures that are closer to CFS when BFS is usually more than 30% better in this area. 8O
On a coreII duo, under ck-sources-3.5.7 with 64 threads, 2000 thread-yields, 16 thread-locks, sysbench reports a total time of
- CFS : 8,8651 s
- (grq-spinlocked) BFS : 5,9689 s
- (urw-locked) BFS : 7,9726 s

BTW, this change is not really meant to stand alone. It is made available with no other goal per se than to test its robustness.
Con gets in his mind a couple of improvements to BFS that are yet only half done and that would rely on this change.
_________________


Last edited by aCOSwt on Mon Mar 25, 2013 8:31 pm; edited 6 times in total
Back to top
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2375
Location: Hilbert space

PostPosted: Mon Mar 25, 2013 8:14 pm    Post subject: Reply with quote

ryao wrote:
ZFS is affected regardless of whether CONFIG_MEMCG is in effect or not.

I stand corrected !
As you are the one who works on the problem, you should with no doubt be trusted more than what I had understood from what I had read.
_________________
Back to top
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2375
Location: Hilbert space

PostPosted: Tue Mar 26, 2013 10:58 pm    Post subject: Reply with quote

Ant P. wrote:
Okay, looks like I have a problem...

Another possible track starts from there : https://lkml.org/lkml/2013/2/21/461
With Linus comment : "Doing things like blindly trusting the firmware data without even validating it is a really really bad idea."

If you confirm then https://lkml.org/lkml/diff/2013/3/26/661/1 is the patch for correcting the bug.

EDIT : Note that nvidia hardware should be concerned as well by this bug, https://lkml.org/lkml/diff/2013/3/26/669/1 is the patch for nouveau.

EDIT2 : The patches mentioned above are apparently not included in the upstream's 3.8.5 patch (I won't bump)

EDIT3 : And not in the upstream's 3.8.6 patch either. (I won't bump)
_________________
Back to top
View user's profile Send private message
Ant P.
Advocate
Advocate


Joined: 18 Apr 2009
Posts: 2204
Location: UK

PostPosted: Thu Apr 11, 2013 10:06 pm    Post subject: Reply with quote

Yeah, today on a whim I went and tried the zen-sources git clone I keep around (`make nconfig` calls it 3.8.6) and still get that problem. No big deal in my case, but I bet more than one person out there's having a bad day...

I tried making radeon a module instead of built-in. It still hangs for a while but I can eventually SSH in. dmesg says this, posting here for reference:
Code:
[    3.022877] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
[    3.022895] IP: [<ffffffffa008617f>] radeon_atombios_get_power_modes+0x6ff/0x830 [radeon]
[    3.022961] PGD 2444e2067 PUD 2444e1067 PMD 0
[    3.022970] Oops: 0002 [#1] SMP
[    3.022976] Modules linked in: snd_hda_intel(+) radeon(+) snd_hda_codec snd_hwdep snd_pcm snd_page_alloc snd_timer drm_kms_helper snd ttm soundcore
[    3.022998] CPU 0
[    3.023004] Pid: 182, comm: modprobe Not tainted 3.8.6-zen+ #9 
[    3.023012] RIP: 0010:[<ffffffffa008617f>]  [<ffffffffa008617f>] radeon_atombios_get_power_modes+0x6ff/0x830 [radeon]
[    3.023049] RSP: 0018:ffff880244523b38  EFLAGS: 00010246
[    3.023055] RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000010
[    3.023061] RDX: ffff880243d9aff4 RSI: 00000000000080d0 RDI: 0000000000000000
[    3.023068] RBP: ffff8802456271b8 R08: ffff880244523b73 R09: 000000000000aff4
[    3.023074] R10: ffff880243d90000 R11: 000000000000ab2a R12: ffff8802460be000
[    3.023080] R13: ffff880243d9aff4 R14: ffff8802460be000 R15: ffff8802460be000
[    3.023087] FS:  00007ff19f822700(0000) GS:ffff88024ec00000(0000) knlGS:0000000000000000
[    3.023094] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    3.023099] CR2: 0000000000000010 CR3: 00000002444df000 CR4: 00000000000007f0
[    3.023105] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    3.023111] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[    3.023118] Process modprobe (pid: 182, threadinfo ffff880244522000, task ffff8802457ea220)
[    3.023124] Stack:
[    3.023128]  ffff880243ced288 0000000000000000 0400080004000800 ffff880243d9aff4
[    3.023138]  ffff880243d9aff4 0000000000000000 0018000000000000 aff4aff401060106
[    3.023147]  0000000000000000 ffff880245627400 ffff8802456271b8 ffff8802460be000
[    3.023157] Call Trace:
[    3.023198]  [<ffffffffa00d73df>] ? radeon_pm_init+0x33f/0x580 [radeon]
[    3.023211]  [<ffffffff81110765>] ? kmem_cache_alloc+0xd5/0xe0
[    3.023248]  [<ffffffffa00a45bd>] ? radeon_modeset_init+0x39d/0xb50 [radeon]
[    3.023285]  [<ffffffffa00aab2c>] ? radeon_ib_ring_tests+0x7c/0xd0 [radeon]
[    3.023318]  [<ffffffffa0081a30>] ? radeon_driver_load_kms+0xe0/0x150 [radeon]
[    3.023330]  [<ffffffff8132d665>] ? drm_get_pci_dev+0x185/0x2c0
[    3.023340]  [<ffffffff812dd1e5>] ? remove_conflicting_framebuffers+0x35/0x60
[    3.023351]  [<ffffffff812aabe8>] ? pci_device_probe+0x98/0xe0
[    3.023360]  [<ffffffff81343798>] ? driver_probe_device+0x68/0x220
[    3.023367]  [<ffffffff813439e3>] ? __driver_attach+0x93/0xa0
[    3.023375]  [<ffffffff81343950>] ? driver_probe_device+0x220/0x220
[    3.023383]  [<ffffffff81341c1d>] ? bus_for_each_dev+0x4d/0x80
[    3.023390]  [<ffffffff81342f08>] ? bus_add_driver+0x178/0x260
[    3.023398]  [<ffffffff81343e04>] ? driver_register+0x84/0x180
[    3.023405]  [<ffffffffa013f000>] ? 0xffffffffa013efff
[    3.023414]  [<ffffffff810002c2>] ? do_one_initcall+0x122/0x170
[    3.023423]  [<ffffffff810a931e>] ? load_module+0x176e/0x1e40
[    3.023430]  [<ffffffff810a5f50>] ? unset_module_init_ro_nx+0x80/0x80
[    3.023438]  [<ffffffff810a9b6d>] ? sys_finit_module+0x8d/0x90
[    3.023448]  [<ffffffff8155c1d2>] ? system_call_fastpath+0x16/0x1b
[    3.023454] Code: 00 49 63 86 14 12 00 00 e9 74 f9 ff ff 31 db 0f 1f 44 00 00 49 63 86 14 12 00 00 83 f8 ff 0f 85 5d f9 ff ff 49 8b 86 f8 11 00 00 <c7> 00 00 00 00 00 49 8b 86 f8 11 00 00 41 c7 86 14 12 00 00 00
[    3.023514] RIP  [<ffffffffa008617f>] radeon_atombios_get_power_modes+0x6ff/0x830 [radeon]
[    3.023548]  RSP <ffff880244523b38>
[    3.023553] CR2: 0000000000000010
[    3.023560] ---[ end trace 19c019ab61b682ad ]---

(I see "remove_conflicting_framebuffers" in there, so I tried disabling efifb and only loading radeon, but that didn't work either.)
Back to top
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2375
Location: Hilbert space

PostPosted: Fri Apr 12, 2013 8:01 am    Post subject: Reply with quote

Ant P. wrote:
Code:
[    3.022877] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010

It looks like a story totally different from what I was imagining.
The story it now looks like is much older as well as above my league :
Code:
radeon_modeset_init+0x39d/0xb50 [radeon]

Could you disable modesetting ? (boot with nomodeset)
_________________
Back to top
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2375
Location: Hilbert space

PostPosted: Sun Apr 14, 2013 10:01 am    Post subject: Reply with quote

aCOSwt wrote:
Ant P. wrote:
Okay, looks like I have a problem...

Another possible track starts from there : https://lkml.org/lkml/2013/2/21/461

If you confirm then https://lkml.org/lkml/diff/2013/3/26/661/1 is the patch for correcting the bug.

EDIT2 : The patches mentioned above are apparently not included in the upstream's 3.8.5 patch (I won't bump)

EDIT3 : And not in the upstream's 3.8.6 patch either. (I won't bump)

This patch is not included in upstream's 3.8.7 either.

I talked with Greg K-H who confirms this patch is not included and won't be included as long as there is no formal request for backporting.

=> If you want your problem solved for 3.8 (patches have been commited for 3.9) could you please first confirm if the above mentioned patch solves your boot under UEFI issue or not ?
_________________
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1122

PostPosted: Sat May 04, 2013 11:03 pm    Post subject: Reply with quote

@aCOSwt
It is really weird: All along I had these time accounting problems with the BrainFuckScheduler patch and now it is the other way round:

Linux-3.9.0
doesn't have ondemand and very strange times accounted to threads. But the new Bfs-rc patch solves my problems ...
_________________
fun2gen2
Back to top
View user's profile Send private message
Ant P.
Advocate
Advocate


Joined: 18 Apr 2009
Posts: 2204
Location: UK

PostPosted: Sat May 04, 2013 11:13 pm    Post subject: Reply with quote

aCOSwt wrote:
=> If you want your problem solved for 3.8 (patches have been commited for 3.9) could you please first confirm if the above mentioned patch solves your boot under UEFI issue or not ?

I'm OK with ignoring it until 3.9, since I'm not using the GPU on that machine and I seem to be the only -ck user who noticed the breakage anyway.
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1122

PostPosted: Sun May 05, 2013 11:13 am    Post subject: Reply with quote

ulenrich wrote:
@aCOSwt
It is really weird: All along I had these time accounting problems with the BrainFuckScheduler patch and now it is the other way round:

Linux-3.9.0
doesn't have ondemand and very strange times accounted to threads. But the new Bfs-rc patch solves my problems ...
I quote myself exceptionally.
I think I had troubles with changing from Linux-3.8 to 3.9 because
make oldconfig
is broken when major release change happens!?! I have just tried Linux-3.9 from other distributions (Tumbleweed,siduction), which behave correctly.

Is it officially supported to do "make oldconfig" in this case? Then this my case would be worth a bug ...
_________________
fun2gen2
Back to top
View user's profile Send private message
xming
Guru
Guru


Joined: 02 Jul 2002
Posts: 434

PostPosted: Mon May 06, 2013 8:17 am    Post subject: Reply with quote

3.9 + ck has been working well here, no crazy times reported by top any more, no issues with make oldconfig here. Just one little issue wit shutdown not actually shutting down, but this is a 3.9.0 issue. Presumably solve by
Code:

commit 0d5cadb87e0fa764db7fa0b78d8a6f173cb475a1
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sat May 4 14:40:51 2013 -0400

    do_mount(): fix a leak introduced in 3.9 ("mount: consolidate permission checks")
   
    Cc: stable@vger.kernel.org
    Bisected-by: Michael Leun <lkml20130126@newton.leun.net>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>


I have tried it yet.
_________________
http://wojia.be
Back to top
View user's profile Send private message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 5610
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Mon May 06, 2013 9:17 am    Post subject: Reply with quote

aCOSwt wrote:
kernelOfTruth wrote:
here's an updated patch: http://pastebin.com/cpqdXZye

Thank you but... warning !
I submitted a patch to Con a couple of weeks ago that looks like... nearly exactly the same as yours...
(We have certainly built it almost the same way)
But Con... did not commit it in his repo so... Might have not been pleased with ?
kernelOfTruth wrote:
any differences and/or improvements you guys noticed with urwlocks in the past ?

Yes, the sysbench --test=threads test reports figures that are closer to CFS when BFS is usually more than 30% better in this area. 8O
On a coreII duo, under ck-sources-3.5.7 with 64 threads, 2000 thread-yields, 16 thread-locks, sysbench reports a total time of
- CFS : 8,8651 s
- (grq-spinlocked) BFS : 5,9689 s
- (urw-locked) BFS : 7,9726 s

BTW, this change is not really meant to stand alone. It is made available with no other goal per se than to test its robustness.
Con gets in his mind a couple of improvements to BFS that are yet only half done and that would rely on this change.


confirmed ! & thanks for posting the stats

yeah, it made BFS worse

so I stopped using it - it works as a proof of concept

but needs some tweaking - would be interesting how Con further improves it ...
_________________
Unofficial minimal livecd x86/amd64 w/reiser4+truecrypt (by Neo2)
2.6.37.2_plus_v1: BFS, CFS,THP,compaction, zcache or TOI
Hardcore Linux user since 2004 :D
Back to top
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2375
Location: Hilbert space

PostPosted: Mon May 06, 2013 12:11 pm    Post subject: Reply with quote

Following BUG 468572 and thanks to Markos Chandras, the ck-sources tree has been updated.

3.8.3 users should upgrade to 3.8.11,
3.4 users should upgrade to 3.4.43
_________________


Last edited by aCOSwt on Tue Jul 23, 2013 4:50 pm; edited 2 times in total
Back to top
View user's profile Send private message
thunderrd
n00b
n00b


Joined: 20 Aug 2010
Posts: 34

PostPosted: Mon May 06, 2013 2:10 pm    Post subject: Reply with quote

Oh, boy.

This is going to make things interesting:

http://lkml.indiana.edu/hypermail/linux/kernel/1305.0/01831.html
Back to top
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2375
Location: Hilbert space

PostPosted: Mon May 06, 2013 2:54 pm    Post subject: Reply with quote

thunderrd wrote:
Oh, boy.
This is going to make things interesting:
http://lkml.indiana.edu/hypermail/linux/kernel/1305.0/01831.html

Hmmm... again interesting those running 4096 cpus systems ? For sure !
As far as I am personally concerned... Hmmm :?
Quote:
CPUs running a single task should be able to utilize a maximum amount of CPU power.

Situations in which I want the maximum amount of CPU power are more of the kind 4096 tasks competing for getting one core than one core having a single task to run. (Which is by the way why I look for the best performing scheduler. Would I even need a scheduler if each of my cores were running a single task ? and of course, if I get nothing to schedule... isn't it just easy to run full tickless ?)
Quote:
A periodic timer tick at HZ=1000 can cause a constant overhead of up to 1.0%. This feature removes that overhead - and speeds up the system by 0.5%-1.0%

Ho fine! On an rt-sources system for which I managed to reach a 2µs max reaction time, I am afraid I just cannot afford the hardware needed to accurately and objectively quantify a 20ns gain.
Quote:
- A single task executing on a CPU is a pretty common situation, especially with an increasing number of cores/CPUs, so this feature helps desktop and mobile workloads as well.

Hmmm... when I consider my personal usage together with my hardware... I just... : smile!

Well... In short, my opinion is that this "enhancement" concerns those systems that get absolutely nothing to schedule.
_________________


Last edited by aCOSwt on Mon May 06, 2013 5:17 pm; edited 4 times in total
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1122

PostPosted: Mon May 06, 2013 3:12 pm    Post subject: Reply with quote

thunderrd wrote:
Oh, boy.
This is going to make things interesting:
http://lkml.indiana.edu/hypermail/linux/kernel/1305.0/01831.html
From above:
Quote:
A periodic timer tick at HZ=1000 can cause a constant overhead of up to 1.0%. This feature removes that overhead - and speeds up the system by 0.5%-1.0%
Me using:
HZ=300
# CONFIG_NO_HZ
as a non-Gamer. I have 5 times a second the chance to intervene. I have better throughput with far less than HZ_1000 due to a third of the irq provoked context switches. NO_HZ_FULL would speed up the system by 0.3%

I consider this a NO_HZ _FULL brainfuck :)
_________________
fun2gen2


Last edited by ulenrich on Mon May 06, 2013 3:14 pm; edited 1 time in total
Back to top
View user's profile Send private message
Ant P.
Advocate
Advocate


Joined: 18 Apr 2009
Posts: 2204
Location: UK

PostPosted: Mon May 06, 2013 3:12 pm    Post subject: Reply with quote

That patch might benefit us normal people too - I've encountered a few systems (mostly laptops) where the hardware is so cheap and crappy you can sometimes *hear* the timer at 1kHz.
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1122

PostPosted: Mon May 06, 2013 3:17 pm    Post subject: Reply with quote

Ant P. wrote:
you can sometimes *hear* the timer at 1kHz.
Then why 1kHZ - see above my use of HZ=300.
_________________
fun2gen2
Back to top
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2375
Location: Hilbert space

PostPosted: Mon May 06, 2013 4:53 pm    Post subject: Reply with quote

ulenrich wrote:
Ant P. wrote:
you can sometimes *hear* the timer at 1kHz.
Then why 1kHZ - see above my use of HZ=300.

@ulenrich : I still assume that I cannot fully catch Ant P.'s humor because of the language barrier, but I would bet there was an appreciable quantity of it in his contribution. :wink:

If I understand correctly, I agree with Ant P. when he suggests that we would all benefit from crappy systems going down to 0 Hz... because they would of course become less... noisy ! :D
_________________
Back to top
View user's profile Send private message
Ant P.
Advocate
Advocate


Joined: 18 Apr 2009
Posts: 2204
Location: UK

PostPosted: Mon May 06, 2013 6:10 pm    Post subject: Reply with quote

aCOSwt wrote:
I still assume that I cannot fully catch Ant P.'s humor because of the language barrier, but I would bet there was an appreciable quantity of it in his contribution. :wink:

There was a bit of that, yeah. :)

My netbook really is noisy at times though, considering it has no moving parts except a fan; in a quiet room it makes an audible clicking that corresponds with the wakeup counts I get in powertop, and a busy CPU causes a faint high-pitched whine. My guess is it's caused by RF interference leaking into the speaker circuit.

I have a vague memory of the early 2.6.x days where 1000Hz was recommended against for similar reasons...
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1122

PostPosted: Mon May 06, 2013 8:14 pm    Post subject: Reply with quote

Ant P. wrote:
I have a vague memory of the early 2.6.x days where 1000Hz was recommended against for similar reasons...
These HZ/NO_HZ are interrupts, it isn't the frequency power your cpu is running! It is the chance when you can intervene in programs. May be ten years ago some of these chances could be missed?
When gaming and when your machine is on its limits I also would suggest a lower HZ, because of better troughput !
_________________
fun2gen2
Back to top
View user's profile Send private message
thunderrd
n00b
n00b


Joined: 20 Aug 2010
Posts: 34

PostPosted: Tue May 07, 2013 8:46 am    Post subject: Reply with quote

Linus is fairly unimpressed, as well:

http://lkml.indiana.edu/hypermail/linux/kernel/1305.0/01867.html

http://lkml.indiana.edu/hypermail/linux/kernel/1305.0/02292.html

This 'enhancement' (as Eric quite nicely calls it, with tongue firmly in his cheek) to me is far too subtle to care about. And not only that, it's going to cost Con tons of time fuxoring about to sync up BFS if it happens. We really don't want that now, do we?

:)
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1122

PostPosted: Tue May 07, 2013 12:44 pm    Post subject: Reply with quote

A friction of 1 percentage performance gain at the cost of complicated untested code?

Isn't it what Karl Marx had to say about: At 5% interested, 10% getting hot, over 20% the kapitalist will consider dead bodies ....
_________________
fun2gen2
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next
Page 5 of 8

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum