=== kmargar is now known as markos_ [09:43] hi, anyone knows of an asm instruction (or instructions) to find out the L1/L2 (well no ARM with L3 cache yet) cache sizes on ARM? Or some way to read it from the kernel? [09:45] similar to cpuid on recent x86 cpus === JaMa is now known as JaMa|Away === fta_ is now known as fta === JaMa|Away is now known as JaMa [16:16] lool: I'm about to give up, no matter what I do, wanna-build just fails to even produce the database, you did mention an alternative a while ago, a gsoc project, got any more info on that? [16:23] markos_: the registers which can be used to get this information are described in ARM ARM, but they are not accessible from userspace [16:24] markos_: kernel provides some of the cpu specific information via /proc/cpuinfo and /proc/self/auxv [16:26] ssvb: cpuinfo doesn't carry this info though, actually I thought of auxv, but it's not straightforward and I thought I'd ask first [16:28] markos_: yes, this information may be incomplete, for example auxv did not even report NEON availability before linux kernel 2.6.29 [16:29] markos_: if you are really interested in having this information, pushing some patches to the kernel to get it may be useful [16:30] markos_: btw, http://pastebin.com/3rvXx68s [16:30] hm, I guess it depends on the platform [16:30] what kernel version? [16:31] 2.6.21-omap1 [16:31] strange, I get none of the cache info here (2.6.31.12.3-ER1-efikamx) on the imx515 [16:31] looks like somebody is being lazy and is not keeping this code up to date :) [16:32] markos_: pkern was working on a python-based wanna-build replacement [16:32] ssvb: still on x86 and ppc, L1/L2 cache info can be found on /sys/devices/system/cpu/cpu0/cache/index# etc [16:33] ssvb: would be nice to have it work the same on arm also [16:33] lool: anything published? [16:34] markos_: google "Debian Autobuilding Infrastructure Rewrite"; I don't know how complete the rewrite ended up being [16:34] markos_: Ping pkern or HE on #debian-devel@oftc? [16:35] markos_: I have only 'cpufreq' there, but not 'cache', anyway it is clearly a problem on the kernel side, preferably it should provide this information in a consistent way [16:36] markos_: alternatively it would be interesting if the kernel could just provide access to cpuid related registers (or emulate their behavior) [16:37] why do you need to know cache size? [16:38] eigen library does block size configuration -or is able to do so- by matching matrix blocks according to the L1/L2/L3 cache sizes, it gets some extra % speed that way -at least on x86 [16:39] there's cpuid on x86 which gives that info -amongst others [16:41] a somewhat ugly solution would be to run a small benchmark to get this information in an experimental way [16:41] that's too error prone [16:41] iirc, fftw does something like this [16:42] right, but in the worst case it will just impact performance, nothing else [16:42] which is the point behind all this :) [16:44] are you going to bug kernel developers about providing this information? [16:44] if it's possible, I can use it, if not, well, eigen is only a linear algebra library, running mini benchmarks at startup isn't going to be accepted by the authors anyway [16:45] ssvb: I might, time permitting [16:45] tbh, I've never filed a bug report on the kernel before, but there's always a first time :) [16:46] the info is already available anyway [16:46] first I have to setup this this autobuilder setup [16:46] s/setup$/ [16:50] lool: I guess soyuz cannot be installed standalone... [16:50] ? [19:25] markos_: No, but we're working exactly on that [19:25] markos_: Actually, according to the soyuz devs it's not that hard to run it standalone [19:26] markos_: What you will miss is the Launchpad API [19:26] and obviously the web UI [19:26] markos_: I'm not sure where the work related to splitting soyuz out is tracked; it should be in a blueprint but I'm not sure where [19:28] markos_: Ideally, ping james_w if you want to follow these discussions