DragonFlyBSD Rewrite KTR logging subsystem (http://gist.github.com/ec5a386cc9c163e26aa9) VFS Quota system Coalesce poll/select/kevent and MPSAFE wakeup DMA retry exponential backoff Port alc(4) network driver (In progress) Port VirtualBox Volume Manager (Research) Lock sfbuf subsystem (In progress) Reimplement lwbuf subsystem locklessly Test openjdk7 (Build fails on x86_64) Make list of possible net changes to bring in to ease driver porting [18:43] <@aggelos> thesjg: re: the volume manager for gsoc... I dunno, even a passthrough vm with a plugin interface seems like a lot if that interface is to be usable [18:44] <@thesjg> hrm [18:47] <@thesjg> dunno, depends on how complete the SoC spec is I guess (how much time they spend researching it beforehand) [18:50] <@thesjg> if there's a reasonable gameplan going in i don't think it would be problematic as long as you aren't trying to implement raid and stuff in the same timeframe [19:01] <@aggelos> hmm. simplistic raid 0/1 should in principle be doable [19:01] <@aggelos> if only to demonstrate the stacking works [19:02] <@thesjg> yes. [19:02] <@thesjg> I was thinking "passthrough" and "stripe" modules [19:03] <@aggelos> but you want to do labeling, and volume detection etc [19:03] <@thesjg> you passthrough each disk and then stripe.. and then stripe again if you want.. to demonstrate stacking [19:03] <@aggelos> hmm [19:03] * vsayer (~vivek@c-76-103-244-154.hsd1.ca.comcast.net) Quit (Read error: Connection reset by peer) [19:03] <@aggelos> I think it's like you said [19:03] <@aggelos> such a project must include a detailed plan [19:03] <@thesjg> maybe its a good idea to work out a plan anyway? [19:04] <@thesjg> even if it doesn't end up as a SoC project? [19:04] <@aggelos> indeed [14:10] <@tuxillo> dillon: btw, the other day I told aggelos that we could change from ulong to int64 the if statistics so they don't wrap so often [14:10] <@tuxillo> he recommended to check all the userland programs that use them to avoid problems [14:10] <@dillon> The IF statistics ? [14:11] <@tuxillo> any other thing to take in account? [14:11] <@tuxillo> network interfaces statistics [14:11] <@dillon> well, if the statistics are not per-cpu then making them 64 bits makes them less MP safe on rollovers [14:11] <@dillon> (I don't remember if they are per-cpu or not) [14:11] <@dillon> generally speaking, though, I think they should be 64-bits [14:12] <@tuxillo> let me check the struct name [14:12] <@tuxillo> dillon: obsd and nbsd did it [14:13] <@tuxillo> dillon: if_stat [14:13] <@tuxillo> dillon: http://grok.x12.su/source/xref/dragonfly/sys/net/if.h#91 [14:14] <@dillon> it isn't per-cpu. We'd probably want to make it per-cpu [14:14] <@tuxillo> out of reach for me [14:15] <@dillon> mmm. some of the if_data elements are fixed, and some are statistics [14:16] <@thesjg> i was about to say [14:16] <@thesjg> should split that struct [14:18] <@thesjg> how does userland get it? sysctl? [14:18] <@dillon> yah, a SYSCTL_PROC rollup would work just fine there [14:19] <@thesjg> yeah [14:19] <@dillon> the real issue is that presumably it makes porting more difficult (slightly) [14:20] <@thesjg> mmm.. its really just in naming or dropping in a cpu index, i wouldn't be concerned i guess [14:20] <@thesjg> should be obvious to a porter [14:20] <@dillon> yah. easy minor port work. we'd separate the structure out and make it an array [14:22] <@thesjg> tuxillo: that would be pretty easy if you wanted to do it [14:24] <@tuxillo> me? [14:25] <@thesjg> tuxillo: sure. not looking for a project? [14:25] <@tuxillo> nope [14:25] <@dillon> basically split struct if_data info struct if_data and struct if_stats [14:26] <@dillon> adjust struct if_msghdr to declare both [14:27] <@tuxillo> hmm [14:27] <@dillon> adjust struct ifnet to declare struct if_stats in an array [14:27] <@dillon> adjust all code references to use the new structure id paths [14:27] <@dillon> adjust the sysctls and/or whatever kerninfo uses to get interface stats to rollup the per-cpu data into a single copy [14:27] <@tuxillo> what about the per-cpu? [14:27] <@dillon> basically that's it [14:28] <@thesjg> tuxillo: that's why you are splitting into an array [14:28] <@tuxillo> ah [14:28] <@dillon> that is the struct if_stats array we would add to struct ifnet [14:28] <@dillon> right [14:28] <@tuxillo> I see [14:28] <@tuxillo> I will have a look to see if I'm able to do it [14:31] <@lentferj> tuxillo: have you tried SMP on KVM? [14:33] <@tuxillo> I'm building up a smp kernel now [14:33] <@tuxillo> why? [14:33] <@tuxillo> maybe it performs like shit [14:33] <@tuxillo> dillon: the struct to MAXCPUS or what?+ [14:34] <@tuxillo> I don't have this per-cpu thingies clear in mind [14:34] <@dillon> yah [14:34] <@dillon> MAXCPU [14:34] <@lentferj> tuxillo: just wondering [14:35] <@tuxillo> do you guys have sometimes like fog in the brain? [14:35] <@thesjg> tuxillo: and index into it with cpuid (its magically always the number of the cpu you are executing on) [14:36] * yugioh (~dasd@ppp-94-68-101-104.home.otenet.gr) has joined #dragonflybsd [14:36] <@dillon> do we have a macro for that? I always use mycpu->gd_cpuid [14:37] <@dillon> probably best to create a macro for accessing if stats. IFSTAT(fieldname) or something like that. #define IFSTAT(fieldname) if_stats[mycpu->gd_cpuid].fieldname [14:38] <@dillon> er, IFSTATS that is [14:39] <@dillon> so you'd do something like ++IFSTATS(myif, fieldname) or something like that. [14:39] <@dillon> #define IFSTATS(if, field) (if->if_stats[mycpu->gd_cpuid].field) [14:39] <@thesjg> dillon: good question, there is use of "cpuid" throughout the kernel, maybe mycpuid too [14:40] <@dillon> ./platform/pc64/include/thread.h:#define mycpuid (_get_mycpu()->gd_cpuid) [14:40] <@dillon> looks like mycpuid [14:41] <@dillon> lets see. or ++myif->IFSTATS(fieldname) [14:41] <@dillon> #define IFSTATS(fieldname) if_stats[mycpuid].fieldname [14:41] <@tuxillo> well, you index it to the current cpu in the cases where it is being filled [14:41] <@tuxillo> what's the max TB for int64? [14:41] <@dillon> 16 million TB I think. not sure [14:42] <@tuxillo> wth? really? [14:42] <@tuxillo> wow [14:42] <@thesjg> tuxillo: right, and then you pull all the values together and roll them up in a sysctl somewhere before you return them to userland [14:42] <@tuxillo> yeah, sure, it's just replacing the split structures in the common places [14:42] <@tuxillo> beer++ [14:42] <@thesjg> hrm, homework done [14:43] <@dillon> 1TB = 2^40, leaving 2^24 = 16 million. So 16 million terrabytes [14:43] <@dillon> (16 exabytes) [14:44] <@tuxillo> less number wrapping then no dillon? :) [14:44] <@thesjg> tuxillo: and that will be per-cpu .. so at least in-kernel you have 16EB*ncpus (potentially) [14:44] <@tuxillo> and humanize_number() can print it even [14:45] <@tuxillo> hm, wait [14:45] <@tuxillo> ah, nothing [14:46] <@tuxillo> roll them up in a sysctl = sum all the cpu stats [14:46] <@tuxillo> *cpu if stats [14:46] <@thesjg> yeah [14:47] <@dillon> struct if_msghdr looks like the primary access method for netif statistics, via the routing socket's RTM_IFINFO command [14:47] <@tuxillo> nbsd kept that struct like it was for COMPAT_* [14:47] <@dillon> looks even easier to do than a sysctl rollup