| 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 me | 00:19 |
|---|---|---|
| rsc | Oh, that's easy to explain ;) | 00:22 |
| rsc | The sources of RHEL will be only available to their customers. | 00:23 |
| rsc | Only the sources of CentOS Stream (the playground/development tree for RHEL, max. 5 years lifecycle) will be available to the public. | 00:24 |
| rsc | The "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 |
| rsc | *restrictions | 00:25 |
| programmerjake | seems like the fsf could sue them... | 00:27 |
| programmerjake | idk if that's the best use of their time and money tho | 00:28 |
| *** JTL <JTL!~jtl@user/jtl> has quit IRC | 05:01 | |
| *** WhyNotHugo <WhyNotHugo!bc7d0f0b52@2604:bf00:561:2000::28> has quit IRC | 05:01 | |
| *** alethkit <alethkit!23bd17ddc6@sourcehut/user/alethkit> has quit IRC | 05:01 | |
| *** JTL <JTL!~jtl@user/jtl> has joined #libre-soc | 05:02 | |
| *** WhyNotHugo <WhyNotHugo!bc7d0f0b52@2604:bf00:561:2000::28> has joined #libre-soc | 05:02 | |
| *** alethkit <alethkit!23bd17ddc6@sourcehut/user/alethkit> has joined #libre-soc | 05:02 | |
| *** WhyNotHugo_ <WhyNotHugo_!bc7d0f0b52@2604:bf00:561:2000::28> has joined #libre-soc | 05:02 | |
| *** JTL <JTL!~jtl@user/jtl> has quit IRC | 05:02 | |
| *** alethkit <alethkit!23bd17ddc6@sourcehut/user/alethkit> has quit IRC | 05:02 | |
| *** WhyNotHugo <WhyNotHugo!bc7d0f0b52@2604:bf00:561:2000::28> has quit IRC | 05:02 | |
| *** alethkit_ <alethkit_!23bd17ddc6@sourcehut/user/alethkit> has joined #libre-soc | 05:02 | |
| *** WhyNotHugo_ is now known as WhyNotHugo | 05:03 | |
| *** alethkit_ is now known as alethkit | 05:03 | |
| *** JTL <JTL!~jtl@user/jtl> has joined #libre-soc | 05:07 | |
| *** markos_ <markos_!~markos_@user/markos/x-1838887> has quit IRC | 05:08 | |
| *** TheDot <TheDot!~TheDot@d66-244-245-228.abol1.o-net.ca> has quit IRC | 05:08 | |
| *** hl <hl!~hl@user/hl> has quit IRC | 05:08 | |
| *** markos_ <markos_!~markos_@user/markos/x-1838887> has joined #libre-soc | 05:09 | |
| *** TheDot <TheDot!~TheDot@d66-244-245-228.abol1.o-net.ca> has joined #libre-soc | 05:09 | |
| *** hl <hl!~hl@user/hl> has joined #libre-soc | 05:09 | |
| *** lkcl <lkcl!lkcl@freebnc.bnc4you.xyz> has quit IRC | 05:10 | |
| *** josuah <josuah!~josuah@46.23.94.12> has quit IRC | 05:10 | |
| *** awilfox <awilfox!~awilfox@kelsey.foxkit.us> has quit IRC | 05:10 | |
| *** sauce <sauce!~sauce@free.and.open.sauce.icu> has quit IRC | 05:10 | |
| *** lkcl <lkcl!lkcl@freebnc.bnc4you.xyz> has joined #libre-soc | 05:10 | |
| *** josuah <josuah!~josuah@46.23.94.12> has joined #libre-soc | 05:10 | |
| *** awilfox <awilfox!~awilfox@kelsey.foxkit.us> has joined #libre-soc | 05:10 | |
| *** sauce <sauce!~sauce@free.and.open.sauce.icu> has joined #libre-soc | 05:10 | |
| *** libredev <libredev!libredev@libredev.ircforever.org> has quit IRC | 05:11 | |
| *** libredev <libredev!libredev@libredev.ircforever.org> has joined #libre-soc | 05:13 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 06:52 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 06:57 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 08: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 called | 09:23 |
| programmerjake | idk, never looked into ubuntu pro | 09:29 |
| *** mx08 <mx08!~mx08@user/mx08> has quit IRC | 09:51 | |
| *** mx08 <mx08!~mx08@user/mx08> has joined #libre-soc | 09:52 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 10:23 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.174.135> has joined #libre-soc | 10:24 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.174.135> has quit IRC | 10:33 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.55.158> has joined #libre-soc | 10:34 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.55.158> has quit IRC | 10:38 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.172.208> has joined #libre-soc | 11:34 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.172.208> has quit IRC | 11:41 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@81.200.17.113> has joined #libre-soc | 11:41 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@81.200.17.113> has quit IRC | 11:46 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 11:58 | |
| *** HumanGeek <HumanGeek!~jerome@82.66.65.160> has joined #libre-soc | 12:23 | |
| lkcl | programmerjake, no they can't... but... hang on... let me think... | 12:28 |
| lkcl | * there's nothing prohibiting the addition of extra clauses | 12: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 |
| lkcl | which means that although Redhat has "complied" with its obligations, it is putting its *customers* in jeapordy! | 12:30 |
| * lkcl facepalm | 12:30 | |
| lkcl | if 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 |
| lkcl | especially if they have no agreement to own their own copyright | 12:32 |
| lkcl | oooo that's a nasty one :) | 12:32 |
| lkcl | RH attempting to place additional clauses *on a Copyright holder*, beyond their reach and right to do so :) | 12:32 |
| lkcl | distributing their *own copyright material* back to them and demanding they sign a prohibition of distribution?? | 12:33 |
| lkcl | ooooo muhahahaha | 12:34 |
| lkcl | that'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 stores | 13:12 |
| markos_ | sorry with VL not MAXVL | 13:12 |
| markos_ | so by any chance, the data is already in cache when it's executed | 13:12 |
| markos_ | thereby negating the use of any explicit prefetch instruction | 13:13 |
| markos_ | s/negating the use/eliminating the need/ | 13:13 |
| markos_ | s/of/for | 13:13 |
| markos_ | sigh | 13:13 |
| lkcl | :) | 13:54 |
| lkcl | that's the kind of thing that would involve a new RFC for a type of "sync" instruction (a la "lwsync") | 13:55 |
| lkcl | it's a great idea | 13:55 |
| lkcl | can you raise it as a bugreport and put 1011 as its parent? (blocks) https://bugs.libre-soc.org/show_bug.cgi?id=1011 | 13:55 |
| markos_ | ok | 13:59 |
| programmerjake | no, 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 memory | 14:08 |
| programmerjake | state 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 |
| programmerjake | cache prefetching is closest to a load instruction | 14:09 |
| programmerjake | by those/these i mean sync* instructions | 14:10 |
| markos_ | I did not say it's a sync instruction | 14: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 VL | 14:12 |
| markos_ | in fact, come to think of it, this should not need any instruction at all | 14:12 |
| markos_ | that's the whole point | 14:12 |
| markos_ | to not need to execute any prefetch instruction for prefetching to work | 14:13 |
| programmerjake | markos, 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 prefetching | 14:14 |
| programmerjake | luke'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 loop | 14:16 |
| markos_ | we've seen that it actually hurts performance on Arm | 14:16 |
| markos_ | so we've disabled it altogether | 14:16 |
| programmerjake | i think a cpu prefetching based on instructions is a good idea, except that kind of logic is how we get spectre v2 | 14:16 |
| markos_ | I don't follow | 14:17 |
| markos_ | we do not change the code, the loads are still there | 14:17 |
| programmerjake | oh, actually, only if prefetching is based on speculative instruction's data | 14:17 |
| markos_ | the cpu will just detect there is a load in the pipeline and set up prefetching on this particular address + for VL elements | 14:18 |
| programmerjake | just prefetching based on decoded ops is fine, except that the address calculation needs to be from only no-longer speculative ops | 14:19 |
| markos_ | yes, such details are important to know, but if it's possible it would give a nice boost | 14:21 |
| programmerjake | otherwise 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 performance | 14:23 |
| programmerjake | if 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 pipeline | 14:23 |
| markos_ | could this be enabled/disabled? | 14:24 |
| programmerjake | spectre isn't about performance, but leaking sensitive data | 14:24 |
| markos_ | I mean such behaviour, could this be a flag that the OS/kernel could set somewhere? | 14:24 |
| markos_ | a cpu state rather | 14:25 |
| programmerjake | probably, but any sane os would set that to not leak data in almost all cases | 14:25 |
| programmerjake | your program would generally have to specifically request fast and leaky mode | 14: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 |
| programmerjake | they 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 see | 14:28 |
| programmerjake | also it might not be only other processes, e.g. js engines running potentially malicious code from the web -- in-process security boundaries | 14:29 |
| programmerjake | for a good description of why sync* is unrelated to cache prefetching, see the section "THE EFFECTS OF THE CPU CACHE" in https://www.kernel.org/doc/Documentation/memory-barriers.txt | 15:00 |
| programmerjake | lkcl ^ | 15:00 |
| programmerjake | generally the only time the cache matters for memory barriers is when I/O devices bypass the cache coherency mechanism and read/write memory directly | 15:03 |
| programmerjake | or 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]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 15:32 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.55.91> has joined #libre-soc | 15:33 | |
| *** tplaten <tplaten!~tplaten@62.144.57.66> has joined #libre-soc | 16: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 <https://libera.ems.host/_matrix/media/v3/download/libera.chat/10c8d8fe08831bcf1c6dfe7b7d66b1f904044c04>) | 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 vacuum | 16:52 |
| sadoon[m] | They expect every company to be an Apple or Microsoft, when RH's model is far from that | 16:53 |
| sadoon[m] | Well, it *was* far from that, now only time will tell. | 16:53 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.55.91> has quit IRC | 17:16 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 17:17 | |
| *** tplaten <tplaten!~tplaten@62.144.57.66> has quit IRC | 18:17 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 18:42 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 18:58 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 21:03 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 21:06 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.55.11> has joined #libre-soc | 21:07 | |
| *** psydroid <psydroid!~psydroid@user/psydroid> has quit IRC | 22:40 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.55.11> has quit IRC | 23:15 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@91.205.168.237> has joined #libre-soc | 23:16 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@91.205.168.237> has quit IRC | 23:28 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.170.76> has joined #libre-soc | 23:28 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!