Friday, 2023-06-23

sadoon[m]My problem is understanding what *actually* changed in the first place, I'll read the full RH release tomorrow because sensationalism might have blurred the image for me00:19
rscOh, that's easy to explain ;)00:22
rscThe sources of RHEL will be only available to their customers.00:23
rscOnly the sources of CentOS Stream (the playground/development tree for RHEL, max. 5 years lifecycle) will be available to the public.00:24
rscThe "Red Hat paywall" includes an EULA with restricts about what is allowed with the packages offered there, which may or may not conflict with the GPL.00:25
programmerjakeseems like the fsf could sue them...00:27
programmerjakeidk if that's the best use of their time and money tho00:28
*** JTL <JTL!~jtl@user/jtl> has quit IRC05:01
*** WhyNotHugo <WhyNotHugo!bc7d0f0b52@2604:bf00:561:2000::28> has quit IRC05:01
*** alethkit <alethkit!23bd17ddc6@sourcehut/user/alethkit> has quit IRC05:01
*** JTL <JTL!~jtl@user/jtl> has joined #libre-soc05:02
*** WhyNotHugo <WhyNotHugo!bc7d0f0b52@2604:bf00:561:2000::28> has joined #libre-soc05:02
*** alethkit <alethkit!23bd17ddc6@sourcehut/user/alethkit> has joined #libre-soc05:02
*** WhyNotHugo_ <WhyNotHugo_!bc7d0f0b52@2604:bf00:561:2000::28> has joined #libre-soc05:02
*** JTL <JTL!~jtl@user/jtl> has quit IRC05:02
*** alethkit <alethkit!23bd17ddc6@sourcehut/user/alethkit> has quit IRC05:02
*** WhyNotHugo <WhyNotHugo!bc7d0f0b52@2604:bf00:561:2000::28> has quit IRC05:02
*** alethkit_ <alethkit_!23bd17ddc6@sourcehut/user/alethkit> has joined #libre-soc05:02
*** WhyNotHugo_ is now known as WhyNotHugo05:03
*** alethkit_ is now known as alethkit05:03
*** JTL <JTL!~jtl@user/jtl> has joined #libre-soc05:07
*** markos_ <markos_!~markos_@user/markos/x-1838887> has quit IRC05:08
*** TheDot <TheDot!> has quit IRC05:08
*** hl <hl!~hl@user/hl> has quit IRC05:08
*** markos_ <markos_!~markos_@user/markos/x-1838887> has joined #libre-soc05:09
*** TheDot <TheDot!> has joined #libre-soc05:09
*** hl <hl!~hl@user/hl> has joined #libre-soc05:09
*** lkcl <lkcl!> has quit IRC05:10
*** josuah <josuah!~josuah@> has quit IRC05:10
*** awilfox <awilfox!> has quit IRC05:10
*** sauce <sauce!> has quit IRC05:10
*** lkcl <lkcl!> has joined #libre-soc05:10
*** josuah <josuah!~josuah@> has joined #libre-soc05:10
*** awilfox <awilfox!> has joined #libre-soc05:10
*** sauce <sauce!> has joined #libre-soc05:10
*** libredev <libredev!> has quit IRC05:11
*** libredev <libredev!> has joined #libre-soc05:13
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC06:52
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc06:57
*** ghostmansd <ghostmansd!> has joined #libre-soc08:39
sadoon[m]Doesn't canonical already do that with Pro?09:21
sadoon[m]Ubuntu Pro*09:23
sadoon[m]Bah, I forget what its called09:23
programmerjakeidk, never looked into ubuntu pro09:29
*** mx08 <mx08!~mx08@user/mx08> has quit IRC09:51
*** mx08 <mx08!~mx08@user/mx08> has joined #libre-soc09:52
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC10:23
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc10:24
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC10:33
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc10:34
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC10:38
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc11:34
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC11:41
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc11:41
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC11:46
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc11:58
*** HumanGeek <HumanGeek!~jerome@> has joined #libre-soc12:23
lkclprogrammerjake, no they can't... but... hang on... let me think...12:28
lkcl* there's nothing prohibiting the addition of extra clauses12:29
lkcl* the GPL states "if you cannot comply with the additional clauses then You must cease and desist distribution and use" (because nothing else but the GPL License grants you the right to use)12:29
lkclwhich means that although Redhat has "complied" with its obligations, it is putting its *customers* in jeapordy!12:30
* lkcl facepalm12:30
lkclif any of its customers have employees that are *also contributors* to any of the FOSS projects distributed through RHEL then those employees are f****d!!!12:31
lkclespecially if they have no agreement to own their own copyright12:32
lkcloooo that's a nasty one :)12:32
lkclRH attempting to place additional clauses *on a Copyright holder*, beyond their reach and right to do so :)12:32
lkcldistributing their *own copyright material* back to them and demanding they sign a prohibition of distribution??12:33
lkclooooo muhahahaha12:34
lkclthat's grounds for a lawsuit :)12:34
markos_lkcl, just a thought, is there a way to somehow link the cache prefetching mechanism with MAXVL? so if for example we have a sv.ld instruction in the pipeline, then the memory unit automatically issues a prefetch *before* the instruction is executed?13:12
markos_similarly for stores13:12
markos_sorry with VL not MAXVL13:12
markos_so by any chance, the data is already in cache when it's executed13:12
markos_thereby negating the use of any explicit prefetch instruction13:13
markos_s/negating the use/eliminating the need/13:13
lkclthat's the kind of thing that would involve a new RFC for a type of "sync" instruction (a la "lwsync")13:55
lkclit's a great idea13:55
lkclcan you raise it as a bugreport and put 1011 as its parent? (blocks)
programmerjakeno, cache prefetching is *not* a kind of sync instruction, those have to do with *memory* ordering (in what order do memory read/writes become visible to other cores, note these do basically the same thing *even if you have no cache whatsoever*, caches are effectively invisible at this level, this invisibility is what the cache coherence protocol is responsible for maintaining (basically, any read to the cache sees the latest memory14:08
programmerjakestate at that location, any write to the cache appears to update all cpu's view of that memory) which is distinct from *cache* management (which caches should data be in)14:08
programmerjakecache prefetching is closest to a load instruction14:09
programmerjakeby those/these i mean sync* instructions14:10
markos_I did not say it's a sync instruction14:11
markos_what I'm suggesting is a way to have a way to detect memory loads/stores in the pipeline, *before* they are executed and triggering prefetching automatically, equal to VL14:12
markos_in fact, come to think of it, this should not need any instruction at all14:12
markos_that's the whole point14:12
markos_to not need to execute any prefetch instruction for prefetching to work14:13
programmerjakemarkos, i know you didn't say it's a sync instruction, luke did (and he's incorrect)14:14
markos_I mean, when an instruction is inserted into the pipeline during its decode phase, some mechanism might be triggered to enable prefetching14:14
programmerjakeluke's incorrect for at least common cpu design terminology, idk if PowerISA does something different cuz it's special (like MSB0)14:15
markos_currently prefetching is a problem, yes, it can help, if data is not in the cache, but it can also slow down if data is already in the cache, you essentially waste an instruction in a critical loop14:16
markos_we've seen that it actually hurts performance on Arm14:16
markos_so we've disabled it altogether14:16
programmerjakei think a cpu prefetching based on instructions is a good idea, except that kind of logic is how we get spectre v214:16
markos_I don't follow14:17
markos_we do not change the code, the loads are still there14:17
programmerjakeoh, actually, only if prefetching is based on speculative instruction's data14:17
markos_the cpu will just detect there is a load in the pipeline and set up prefetching on this particular address + for VL elements14:18
programmerjakejust prefetching based on decoded ops is fine, except that the address calculation needs to be from only no-longer speculative ops14:19
markos_yes, such details are important to know, but if it's possible it would give a nice boost14:21
programmerjakeotherwise we're changing cache state based on speculative ops which doesn't get reset if those ops turn out to not be executed (e.g. a bounds check on a buffer failed, allowing the speculative base address to be based on a load out of bounds which leaked sensitive data to the cache's state)14:21
markos_in that case, the cpu will be prefetching data that will not get used which does no actual harm in performance14:23
programmerjakeif you don't care about spectre and want more speed at any cost then go ahead and prefetch based on any vector load in the pipeline14:23
markos_could this be enabled/disabled?14:24
programmerjakespectre isn't about performance, but leaking sensitive data14:24
markos_I mean such behaviour, could this be a flag that the OS/kernel could set somewhere?14:24
markos_a cpu state rather14:25
programmerjakeprobably, but any sane os would set that to not leak data in almost all cases14:25
programmerjakeyour program would generally have to specifically request fast and leaky mode14:25
markos_why is that a security risk?14:25
markos_other processes cannot access the contents of data in the cache that does not belong to them anyway, can they?14:27
programmerjakethey can, if run on the same cpu core, since oses don't cache flush on context switch (which would kill perf)14:28
markos_I see14:28
programmerjakealso it might not be only other processes, e.g. js engines running potentially malicious code from the web -- in-process security boundaries14:29
programmerjakefor a good description of why sync* is unrelated to cache prefetching, see the section "THE EFFECTS OF THE CPU CACHE" in
programmerjakelkcl ^15:00
programmerjakegenerally the only time the cache matters for memory barriers is when I/O devices bypass the cache coherency mechanism and read/write memory directly15:03
programmerjakeor if you're on Alpha (cuz Alpha's weird)15:04
markos_yes, I've had my fun playing with non-cache coherent cpus in the past (MPC5200B) :)15:29
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC15:32
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc15:33
*** tplaten <tplaten!~tplaten@> has joined #libre-soc16:11
sadoon[m]<lkcl> "that's grounds for a lawsuit :)" <- I don't claim to fully understand the situation yet but one thing I'm sure of:... (full message at <>)16:51
sadoon[m]The Silicon Valley way of doing business is they expect exponential growth or bust. Extremely lethal for projects like Red Hat that were absorbed into that vacuum16:52
sadoon[m]They expect every company to be an Apple or Microsoft, when RH's model is far from that16:53
sadoon[m]Well, it *was* far from that, now only time will tell.16:53
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC17:16
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc17:17
*** tplaten <tplaten!~tplaten@> has quit IRC18:17
*** ghostmansd <ghostmansd!> has quit IRC18:42
*** ghostmansd <ghostmansd!> has joined #libre-soc18:58
*** ghostmansd <ghostmansd!> has quit IRC21:03
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC21:06
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc21:07
*** psydroid <psydroid!~psydroid@user/psydroid> has quit IRC22:40
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC23:15
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc23:16
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC23:28
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc23:28

Generated by 2.17.1 by Marius Gedminas - find it at!