=== gerald is now known as Guest29260 [04:04] huh? [04:08] RAOF: i don't recall seeing that before [04:11] tjaalton: Hm. I thought you were talking on #intel-gfx about some hardware context not being there? [04:14] wwll bdw has bugs, but i bet this is with something older [04:24] https://bugs.freedesktop.org/show_bug.cgi?id=75723 it seems [04:24] Freedesktop bug 75723 in Drivers/DRI/i915 "(regression since Linux 3.14?) brw_get_graphics_reset_status: Assertion `brw->hw_ctx != ((void *)0)' failed" [Normal,New] [04:27] Ah. [04:33] love how it's been opened a month ago with zero interest [05:40] yo [06:58] µ’ [07:08] n'? [07:09] cat [07:09] explains all typos from me [07:10] heh :) [07:10] Luckily mine stays outside (unless I fail to prevent him) normally [07:16] i read that as "micro tic" which is close to a router company "microtik" or a new way to wave on IRC ;) [07:23] whatever works :) [07:47] * apw yawns [07:53] apw, Caution there are giant bees approaching from Australia [07:55] smb: Yet he comes back? [07:55] smb: (re: The cat, not the bees) [07:56] soren, Ah, I was wondering. Yes, he does. Apart of being his can opener, he thinks he has to inspect all rooms from time to time [07:57] smb: Interesting. [07:57] smb: I just thought cats were smarter than that. If he wants to go out, but coming into your house means being prevented from going back out, I'd assume he'd not come back. [07:57] smb: That's the argument I use with my wife for letting our cat out whenever he wants. :) [07:58] soren, He is smart enough to actually make use of many people. So he isn't owned by anyone but gets treats everywhere [07:59] Its a shared cat [08:01] smb: Clever. [10:40] how can i monitor actual cpu frequency (as opposed to nominal cpu steps, e.g. while running overclocked or using turbo mode) [10:43] erle-, sudo cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq has instantaneous levels [10:44] apw, that one only tells me nominal states [10:44] but i found the solution in the meanwhile [10:44] from packe linux-tools the command turbostat [10:44] ok good [10:46] i thought you need to look at scaling_cur_freq for the realtime data [10:47] ogra_, both only display the steps of 800,1600,2400 and 3200 [10:48] ogra_, i run at 3712 (highest regular step) and 4176 (turbo) [10:48] bios tells me [10:48] i want to know whether linux uses the turbo [10:48] (AMD turbo [10:48] ) [10:57] does anybody here have experience with amd turbo core? [10:58] i disabled 4 of 6 cores in bios and overclocked, because i want to run a hard single-threaded simulation [10:58] turbo core requires half of cores to be idle [10:58] do disabled cores count as idle? === psivaa is now known as psivaa-lunch === cmagina-away is now known as cmagina === psivaa-lunch is now known as psivaa [14:14] is there a way to dynamically raise the ringbuffer size ? i try to debug some boot stuff, but by the time i can read dmesg or kern.log the buffer is already overwritten [14:16] ogra_, yeah there is a kernel parameter for that [14:16] remember which ? [14:17] ogra_: kernel-parameters.txt talks about log_buf_len [14:17] (never used it myself) [14:17] log_buf_len = bytes i think [14:18] henrix, thanks ! [14:18] will try [14:18] ogra_, no spaces around the ' = ' [14:19] yeah [14:19] rtg, there is habit for you === gerald is now known as Guest45137 [14:57] and it needs to be a power of 2 [15:43] rtg: do you remember if chiluk was hitting this issue on T only? [15:43] rtg: maybe i discarded these patches from 3.11 stable too early... [15:44] although the backport could be non-trivial [15:46] henrix, pretty sure it was on T [15:46] rtg: ack [15:47] henrix, I'm not sure those VFS patches would be right for 3.11 [15:48] rtg: yeah, i dropped them, but i admit i didn't tried too hard to understand the issues they solve... :-/ [15:50] henrix, it might just be the namespace mount point proliferation problem. I wonder if hallyn would know. [15:54] ? [15:54] hallyn, these commits in 3.14: [15:54] 38129a1 switch mnt_hash to hlist [15:54] 0b1b901 don't bother with propagate_mnt() unless the target is shared [15:54] 1d6a32a keep shadowed vfsmounts together [15:54] 0818bf2 resizable namespace.c hashes [15:55] do they help the performance of removing mount points ? [15:55] sorry i haven't seenthem [15:55] certainly 0b1b901 should [15:55] rtg, was that arges' bug perhaps [15:55] as should the first [15:56] apw, I thought it was chiluk ? [15:56] oh maybe, perhaps i need a beer to remind me [15:56] apw, whoa, it _is_ about that time. [15:57] way past [15:57] *burp* [15:57] drat i'm in the wrong tz [15:57] * hallyn swigs some coffee, wishing it were something else [15:58] hallyn, could you have a look at those commits ? They are scheduled for 3.13 stable, but I might pull them earlier and get some testing on them. [15:58] rtg: meeting coming up, i'll look after that [15:59] hallyn, thanks [15:59] np - ttyl [16:01] hallyn: apw : yea it was chiluk's bug [16:19] rtg henriz 0818bf27c05b2 is the important one that should be included in all stable kernels. [16:19] give me a sec to take a look.. [16:20] chiluk`, well, its not in Trusty [16:20] although the move to hlist for m_hash is not necessary [16:21] though it is marked for stable [16:35] Not at all meaning to sound negative, and also, since I'm a fan of you know who, it's SRU up your ass time again! [16:36] infinity: Any chance you'll be SRU'ing linux-lowlatency at next point release to a newer version? I've been meaning to try make that happen, but perhaps now I don't even need to? === chiluk` is now known as chiluk [16:57] Just to clarify, was just quoting Metallica before. [17:53] ogasawara, contrary to your meeting notes, I _do_ plan to upload once more before freeze, if for no other reason then to remove lttng in favor of the lttng-modules package. [17:54] rtg: oh you do? when do you think you'll do the upload? [17:54] rtg: tomorrow? [17:54] ogasawara, I guess it'll have to be tomorrow won't it. Thursday my time would be too late. [17:55] rtg: ok cool, I'll see if I can squeeze in this patch I've been bisecting for [17:55] rtg: just depends on how quickly I can get this testing feedback [17:55] ogasawara, ack [18:21] chiluk: so why is 0818bf27c05b2 important? [18:22] it seems to me that commit 38129a1 is important as otherwise we risk infinite loops when racing withumounts (if the description is to be believed) [18:22] and commit 1d6a32a seems to be a prereq for that one [18:23] hallyn, so openstack neutron nodes keep the network processes in network namespaces and mount namespaces... unfortunately that means that for n network namespaces... there has to be n^2 entries in the mount_hashtable. [18:23] commit 0b1b901 seems unimportant - we only save a lock_mount_hash (and unlock), so unless we are seeing that as a hot path somewhere... [18:23] so for 4000 namespaces that means 1.6m entries in that hashtable. [18:23] which becomes a serious bottleneck, and can also lead to hangs and crashing [18:23] chiluk: ok andn so switching to hlist halves the size of that table? [18:24] hlist isn't as important as increasing the size of the hashtable itself. [18:24] but hlist would help as well. [18:24] i'd be curious to see how much kmem you save then with both 38129a1 and 0b1b901 [18:24] uh, i mean and 0818bf2 [18:25] chiluk: so you would agree that commit 0b1b901 seems unimportant? [18:26] well since they all are meant to improve the performance of the mount namespaces, I would think they are all important... some more than others. [18:27] 0818bf2 should go into all p+ kernels imho [18:27] 0818bf2 1d6a32 0b1b901 38129a13 should all go into trusty. [18:27] if they don't clean cherry-pick, I'll work on a backport. [19:13] chiluk: 4000 network namespaces? Is that a number you're making up or does someone claim to need anything even close to that? [19:14] chiluk: It just sounds a bit over the top to me. Even with a 64 CPU system with, say, 8 VM's per CPU, you'd need an average of 8 distinct networks per VM to reach that number. [19:17] soren... look at openstack .. and yes 4000 is only a small part for a decent sized cloud. [19:18] it's not the compute nodes that are the problem. [19:18] chiluk: Oh, right, the network nodes need to accommodate every single network. [19:19] soren it's the network gateways... mount/net namespaces are used to partition the network by the neutron nodes [19:19] chiluk: Gosh, yes, 4000 aren't going to get you anywhere then. [19:19] exactly [19:19] * soren shakes his head at that horrible design [19:19] right now most people scale out their gateways [19:19] but some people have beefy gateways, and are pissed at the 3-4k limitation. [19:20] chiluk: Understandable. [19:20] chiluk: Yeah, I totally hadn't thought of the network nodes. It makes much more sense that way. [19:21] with these patches those people can take the current 4k hashtable and make it 512mb or more... and get much better performance on deletion.. [19:21] which is usually where the problems started. [19:21] it used to be a 4k hashtable with 80k node linked lists... [19:22] Oh, it doesn't remove the O(n^2) space complexity? [19:22] Oh, my. [19:22] it does not. [19:22] Yeah, that sounds like no fun at all. [19:23] the issue with O(n^2) comes from the lack of forsite in the unshare(CLONE_NEWNS) calls [19:23] and the fact that each new net namespace creates it's own mount... [19:23] for proc entries. [19:24] * soren doesn't quite grok how that becomes an n^2 thing [19:25] each namespace creates a mount... each namespace duplicates all mounts for it's namespace. [19:26] Oh. [19:26] or at least creates duplicate entries in those tables for it'a namespace. [19:42] if you're doing network namespaces it's not strictly necessary to have fresh mounts ns in each netns [20:17] zequence: You might need to rephrase your question. [21:02] infinity: are you going to SRU the trusty kernel to precise later? [21:03] zequence, if you are asking if there will be an lts-backport-trusty kernel for precise the answer is yes [21:03] zequence, that is also why there will be a 12.04.5 release [21:06] zequence: However, the answer to the question you were really asking (does linux-lts-trusty include lowlatency) is currently "no". [21:07] And will probably remain no for that backport. [21:07] But for 14.10 kernels backported to trusty, I think we should enable all flavours. [21:07] infinity: Alright [21:50] Hello. I'm newbie to kernel development. I'm trying to load a module I wrote, but I'm getting the error "Invalid module format". Can anyone help me with this? === hatch__ is now known as hatch === hatch__ is now known as hatch