=== kmargar is now known as markos_ | ||
markos_ | 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:43 |
---|---|---|
markos_ | similar to cpuid on recent x86 cpus | 09:45 |
=== JaMa is now known as JaMa|Away | ||
=== fta_ is now known as fta | ||
=== JaMa|Away is now known as JaMa | ||
markos_ | 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:16 |
ssvb | markos_: the registers which can be used to get this information are described in ARM ARM, but they are not accessible from userspace | 16:23 |
ssvb | markos_: kernel provides some of the cpu specific information via /proc/cpuinfo and /proc/self/auxv | 16:24 |
markos_ | 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:26 |
ssvb | markos_: yes, this information may be incomplete, for example auxv did not even report NEON availability before linux kernel 2.6.29 | 16:28 |
ssvb | markos_: if you are really interested in having this information, pushing some patches to the kernel to get it may be useful | 16:29 |
ssvb | markos_: btw, http://pastebin.com/3rvXx68s | 16:30 |
markos_ | hm, I guess it depends on the platform | 16:30 |
markos_ | what kernel version? | 16:30 |
ssvb | 2.6.21-omap1 | 16:31 |
markos_ | strange, I get none of the cache info here (2.6.31.12.3-ER1-efikamx) on the imx515 | 16:31 |
ssvb | looks like somebody is being lazy and is not keeping this code up to date :) | 16:31 |
lool | markos_: pkern was working on a python-based wanna-build replacement | 16:32 |
markos_ | ssvb: still on x86 and ppc, L1/L2 cache info can be found on /sys/devices/system/cpu/cpu0/cache/index# etc | 16:32 |
markos_ | ssvb: would be nice to have it work the same on arm also | 16:33 |
markos_ | lool: anything published? | 16:33 |
lool | markos_: google "Debian Autobuilding Infrastructure Rewrite"; I don't know how complete the rewrite ended up being | 16:34 |
lool | markos_: Ping pkern or HE on #debian-devel@oftc? | 16:34 |
ssvb | 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:35 |
ssvb | markos_: alternatively it would be interesting if the kernel could just provide access to cpuid related registers (or emulate their behavior) | 16:36 |
ssvb | why do you need to know cache size? | 16:37 |
markos_ | 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:38 |
markos_ | there's cpuid on x86 which gives that info -amongst others | 16:39 |
ssvb | a somewhat ugly solution would be to run a small benchmark to get this information in an experimental way | 16:41 |
markos_ | that's too error prone | 16:41 |
ssvb | iirc, fftw does something like this | 16:41 |
ssvb | right, but in the worst case it will just impact performance, nothing else | 16:42 |
markos_ | which is the point behind all this :) | 16:42 |
ssvb | are you going to bug kernel developers about providing this information? | 16:44 |
markos_ | 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:44 |
markos_ | ssvb: I might, time permitting | 16:45 |
markos_ | tbh, I've never filed a bug report on the kernel before, but there's always a first time :) | 16:45 |
markos_ | the info is already available anyway | 16:46 |
markos_ | first I have to setup this this autobuilder setup | 16:46 |
markos_ | s/setup$/ | 16:46 |
markos_ | lool: I guess soyuz cannot be installed standalone... | 16:50 |
markos_ | ? | 16:50 |
lool | markos_: No, but we're working exactly on that | 19:25 |
lool | markos_: Actually, according to the soyuz devs it's not that hard to run it standalone | 19:25 |
lool | markos_: What you will miss is the Launchpad API | 19:26 |
lool | and obviously the web UI | 19:26 |
lool | 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:26 |
lool | markos_: Ideally, ping james_w if you want to follow these discussions | 19:28 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!