[16:01] Welcome to the Linux Plumbers Conference 2020 Microconference3/Virtual-Room!

Please remember that the LPC anti-harassment policy applies to interaction in this room, and that this room is being recorded.

Please keep your microphone muted and your video off except when participating in the discussion.

This server is running BigBlueButton. [16:45] YouTube Live : This meeting is streaming live on YouTube [17:00] Jonathan Corbet : Wow Arnd you didn't have to dress up just for us :) [17:01] Will Deacon : Make sure he doesn't try to sell you a car :) [17:01] Christian Brauner : He lives in the right area for that. :) [17:01] Russell King : What if we don't have a video camera? [17:02] Mike Rapoport : russel you can raise a hand (click on your user name) [17:02] Mike Rapoport : not sure how this would appear though [17:03] Jonathan Corbet : Russell: just speak up, the raised hand is hard to see [17:05] Paul Walmsley : Do we agree on a definition of "obsolete hardware" ? "No commercial value any more" ? [17:05] Leon Romanovsky : We (RDMA) have very simple criteria: as long as we can buy the hardware on ebay, we will support HW. [17:06] Mike Rapoport : Paul: wouldn't say so [17:06] Mike Rapoport : Look at m68k [17:06] Will Deacon : Wow, "ebay" is pretty broad though. You can still get PDP-11 parts on there (and they're mega expensive) [17:07] Mike Rapoport : I think SGI Octeon was just merged last year [17:07] Leon Romanovsky : Right, but can you buy full PDP system? [17:08] Leon Romanovsky : At least for drivers, this definition worked well, we rmeoved two drivers in last year or two [17:09] Yazen Ghannam : is there an official policy/procedure for marking something obselete? [17:09] Maciej Machnikowski : What would be the criteria that would classify the HW as "obsolete"? [17:09] Geert Uytterhoeven : chat... 502 bad gateway? [17:10] Vinod Koul : 502 for me as well [17:10] Tim Bird : updating docs is easier if there's no requirement to build it. [17:10] Jason Gunthorpe : I like the idea of config obsolete [17:10] Tim Bird : So maybe a text file instead of rst [17:11] Jonathan Corbet : Chat here or rocketchat? [17:11] Geert Uytterhoeven : The advantage of Kconfig is that it's close to the code [17:11] Mark Brown : rocketchat [17:11] Mike Rapoport : jejb just rebooted it [17:11] Tim Bird : I'm getting a 502 from rocketchat [17:11] Mark Brown : been down for a while according to the retry timer in my browser [17:12] Maciej Machnikowski : it sometime may be hard to decide that the HW is no longer made by the manufacturer - sometime there are OEMs buying some old HW that is no longer publicly sold [17:12] Mark Brown : Some hardware never really hits the open market in the first place. [17:12] Alexandra Winter : Which is the session tomorrow, where you discuss Big Endian? "SoC support lifecycle in the kernel" ? [17:12] Yazen Ghannam : so would this tie into the ABI rules? [17:14] Vinod Koul : rocketchat is up for me now [17:15] Russell King : My EBSA285 (Foorbtidge) is still running here with a modern kernel - Linux flint 5.6.12+ #92 Thu May 21 13:43:50 BST 2020 armv4l armv4l armv4l GNU/Linux [17:16] Geert Uytterhoeven : Alexandra: SoC support lifecycle in the kernel [17:16] Linus Walleij : My Footbridge netwinder is running too, just for tests but it is a user. [17:16] Russell King : How long I keep that machine running, I'm not sure, but the code has tended to be relatively stable and hasn't required much fixing. [17:17] Geert Uytterhoeven : rmk: same for m68k. Still runs modern kernels. [17:17] H. Peter Anvin : Alpha is a problematic example: Alpha was the only architecture which didn't support termios2 for over a decade, so glibc never enabled it. [17:17] H. Peter Anvin : Does anyone running Alpha anymore? [17:17] Christian Brauner : Yes, there are alpha users [17:17] Christian Brauner : There are some at HU Berlin and I think Debian has some machines. [17:18] H. Peter Anvin : Is anyone taking responsibility for keeping Alpha up to date with everything else? [17:18] Christian Brauner : Hm, I see people reporting issues if it's broken. [17:19] Darren Kenny : Could we do a phased approach where a 'to be obsoleted' device or code could be flagged at kconfig time but also switch from being automatically enabled to disabled unless a given switch is given on the boot command line, forcing people to pay attention, but still be able to use it. Later, with a specific target release provided at the time of deprecation, that can set a timeline for consumer to work with, or specifically request to extend if they need it. [17:19] Christian Brauner : But not sure if there are actually people fixing bugs. [17:19] Cornelia Huck : QEMU> I think we want 'hardware' to include emulated and virtualized devices/architectures as well (at least the less exotic ones) [17:19] H. Peter Anvin : I ended up implementing termios2 for Alpha, but glibc deprecation rules means that glibc needs termios1 *only* for Alpha [17:20] H. Peter Anvin : It's not just about fixing bugs. It is about keeping up with the remaining kernel for the purpose for the user space API [17:20] H. Peter Anvin : As far as I know, it is still not possible to use termios2 on glibc [17:21] H. Peter Anvin : So we lost 12+ years of having a feature in the kernel but not in user space [17:21] H. Peter Anvin : Worse, the ioctls were broken in the glibc headers [17:21] Russell King : EBSA110 can go away... haven't run that machine for quite some time! [17:21] Christian Brauner : I don't know about that termios2 thing. I just know we have users on fairly recent kernels: cbrauner@tsunami:~$ uname -a Linux tsunami 5.4.0-2-alpha-generic #1 Debian 5.4.8-1 (2020-01-05) alpha GNU/Linux [17:22] Russell King : Unless someone wants to take the machine off my hands... I suspect not though. [17:22] Will Deacon : "Linus Walleij is typing", haha, guess where the ebsa is going? [17:23] Linus Walleij : Russell: Its one of the few using gettimeoffset so would be good to get rid of it. [17:23] Paul Walmsley : :-) [17:23] Russell King : Linus: yes ;) [17:23] Florian Weimer : My understanding was that termios2 needed some ABI transition, and those are difficult and costly. Having the interfaces under different names would help, if they fill gaps. [17:23] Linus Walleij : Russell: will you patch it out or should I? [17:23] Veronika Kabatova : Agreed with Len - the developers will rarely update docs and the users will only ever read the kconfig entries when they want to enable/disable something, not docs. No one checks docs unless something goes terribly wrong ;) [17:24] Russell King : Linus: I'll send a patch to the soc guys [17:24] Linus Walleij : Russell: excellent thanks. [17:24] Helge Deller : Debian still runs many old architectures and builds packages with recent Linux kernels: https://monitor.jrtc27.com/ [17:24] H. Peter Anvin : Florian: only for a small handful of architectures, mainly SPARC [17:24] Mark Brown : My understanding of the proposal was more about it being a contact list than documentation. [17:24] H. Peter Anvin : Florian: and that coudl have been addressed ages ago [17:25] Masami Hiramatsu : Hello [17:25] Mark Brown : ie, "X is using this for Y" type stuff - "it might look unused but it isn't" [17:26] Masami Hiramatsu : Thanks Guo for working on kprobes :) [17:28] Peter Zijlstra : /me waves @Masami [17:29] Li Wang : cute baby voice in background :) [17:29] Mike Rapoport : @all, I'd appreciate help with shared notes [17:30] Arnd Bergmann : Once we remove EBSA110, ARCH_USES_GETTIMEOFFSET can finally be killed off, which should make tglx happy [17:30] Linus Walleij : Yes actually the very last machine using gettimeoffset, removing EBSA110 makes us 100% GENERIC_CLOCKEVENTS. Nice [17:30] Arnd Bergmann : which is the exact kind of information that I want to have documented ;-) [17:31] Mike Rapoport : @arnd, you need to send an example patch and then the flames will start ;-) [17:31] Russell King : Arnd: yes. I do think that your idea of documenting those that are still in use is a good idea - but what's the cut-off for documenting that? I mean, at what point do we start documenting what we currently support to say it's not yet obsolete? [17:32] Masami Hiramatsu : another restriction on x86 is to make sure no other jump instruction jump into the middle of replaced instruction stream. [17:32] Russell King : Do we document a brand new platform? Or only platforms that are five years old? [17:33] Arnd Bergmann : @rmk: I would start with the oldest ones, and those that people have asked about getting rid of in the past [17:33] William Cohen : arm32 kprobes optimization is currently broken: https://bugzilla.redhat.com/show_bug.cgi?id=1870223 [17:34] Russell King : William: anyone working on fixing it or diagnosing the problem? [17:34] Masami Hiramatsu : @William: thanks for the info. I';; check it. [17:35] William Cohen : @Russell King. I did some basic triage to verify that it wasn't due to systemtap., but I don't know anyone working on it. [17:35] Arnd Bergmann : @rmk: I would probably want to add an entry for every 32-bit architecture, and one for every armv4/4t/5/6 platform, along with higher-level entries pointing to those [17:36] Mike Rapoport : and 64-bit alpha and ia64 [17:36] William Cohen : @Masami thanks for taking a look at it. [17:38] atish patra : I think Mike is the presenter now [17:39] Naveen Rao : Sorry, Guo if I broke your flow [17:39] Mike Rapoport : yes, I think guo has disconnected [17:41] atish patra : What does the white symbol says ? audio not connected ? [17:41] Mike Rapoport : yep [17:41] Masami Hiramatsu : Unless you are using stop_machine() self-modifying, mixing opcode might not matter. [17:43] Mike Rapoport : Peter: we can't hear [17:43] Peter Zijlstra : Mike, didn't say anything, didn't want to interrupt too badly [17:44] Mike Rapoport : Oh. sorry :) [17:46] Masami Hiramatsu : Actually, jump optimization method for RISC processors are written in dyninst/paradyn papers 20yrs ago. https://www.dyninst.org/ [17:46] Palmer Dabbelt : so we need to fix the modules thing anyway [17:52] Masami Hiramatsu : @Guo, Let's continue to talk in hackroom :) [17:53] Masami Hiramatsu : Thanks Guo! [17:53] Naveen Rao : @Guo, great talk, thanks! [17:54] Guo Ren : Thx [17:54] Greentime Hu : Thanks @Guo. :) [17:57] Naveen Rao : @Guo, we are in hackroom 3 if you want to join in the discussion [18:06] Michael Ellerman : Identifying good targets for consolidation would be a good first step. [18:06] Geert Uytterhoeven : Yeah, so recently we got lots of new syscalls ;-) [18:06] Mike Rapoport : @mpe vdso mapping? [18:07] Geert Uytterhoeven : Perhaps it became too easy to add new syscalls? [18:11] Russell King : Aren't features like this a multi-stage process - first, the feature needs to be implemented in generic code, with architecture backends. Then the architecutre maintainers need to make it work there. Then, we need to go through the implementations, seeing what has ended up being common amongst all implementations. [18:12] Russell King : The problem is, how does the last step happen... [18:12] Will Deacon : I'm inclined to agree. Making something generic with only one or two users, is unlikely to be generic enough for the array of architectures we end up needing to support. [18:13] Mark Brown : and having to refactor the generic code is immensely painful for submitters. [18:13] Mark Brown : (going round the houses getting all existing architectures to review changes and so on) [18:16] Paul Walmsley : And any generic code changes that affect multiple architectures would need to be tested on all the different architectures. Could be tricky [18:16] Mike Rapoport : it is tricky, but became easier with qemu [18:17] Mike Rapoport : the other side of the coin, that some updates require x24 effort because they are copied [18:17] Mark Brown : Then the person who has to do those 24x updates has the motivation :) (and the overview of things TBH) [18:17] Paul Walmsley : There are some kinds of changes that are probably easy to test with QEMU. Like your mm work. But others that may have CPU microarchitectural side effects could be tricky [18:17] Russell King : Mark: yes [18:18] Cornelia Huck : how good is QEMU coverage of linux architectures? The 'big' ones are generally well supported; but what about the not-so-common ones? Have people fallen into gaps? [18:19] Jonathan Cameron : There is at least some stuff in arch code that was always generic, but is mostly about new arches trying not to carry legacy mess. e.g. most of the numa stuff. [18:19] Mike Rapoport : Corenlia: there are gaps [18:19] Cornelia Huck : I expected that :) which ones are the most important? [18:19] Mike Rapoport : I don't know how to prioritize the importance :) [18:20] Mike Rapoport : for me ia64 is the most problematic [18:20] Cornelia Huck : yes, I don't see a lot of motivation for ia64 [18:20] Christian Brauner : Just from personal experience: when I did the fork cleanup across all architectures that sill used legacy fork it took me a long time because of cross-compiling and testing. [18:20] Christian Brauner : And I wasn't payed . I jus tdid this for fun. [18:21] Christian Brauner : And it's a high bar to require that imho [18:21] Mike Rapoport : MarkR: can you increase mic volume please [18:21] Will Deacon : You need a hobby, Christian. [18:21] Christian Brauner : So I agree with Will [18:21] Christian Brauner : :D I do [18:21] Christian Brauner : /me eyes his ia64 next to him... [18:23] Christian Brauner : The "rest don't matter" is that an argument one can use when sending patches? [18:23] Christian Brauner : I'm seriously asking [18:25] Jonathan Cameron : Rest don't matter, might make sense for unification questions. [18:25] H. Peter Anvin : A reasonable extended set is what is supported in glibc [18:25] Christian Brauner : Fair points. [18:26] H. Peter Anvin : x86, ARM64, ARM32, RISC-V and PPC would be my feeling for first- and second-tier archs [18:27] Cornelia Huck : /me waves the s390 flag [18:27] Will Deacon : m68k and s390 are very well maintained [18:27] Will Deacon : ah good, Cornelia is here [18:28] Mike Rapoport : mips [18:28] Arnd Bergmann : @everyone: please help with the shared notes, we missed out taking notes for most of the previous topic [18:29] Russell King : Arnd: oh, missed that, did any of my comments here from previous sessions get picked up? [18:29] Peter Jones : @Mike: I think the people doing the ASLR analysis of MIPS might disagree [18:30] Mike Rapoport : rmk: we save the entire chat [18:30] Michael Ellerman : I often look at s390 when I'm looking for some code to copy. [18:30] Arnd Bergmann : RISC-V is actually still catching up on a lot of features, so while it is obviously going to be important in the future, it's hard to require every new feature to be there [18:30] Mike Rapoport : @Peter I meant MIPS is an active arch [18:31] Palmer Dabbelt : ya, I don't think we can mandate that all new arch-specific features go in RISC-V [18:31] Will Deacon : mpe: "code to copy" You're part of the problem, huh?! [18:31] Palmer Dabbelt : we're just missing too much stuff at the ISA level to implement a lot of interesting stuff [18:31] Peter Jones : @Mike My point as that I think it /should/ be (there's still tons of it shipping), but there's evidence that it isn't. [18:31] Arnd Bergmann : @rmk: I think the public chat is going to be retained, but the shared notes are separate and I don't think they got copied in there, feel free to add anything you find important from your comments (or anyone else's there) [18:33] Mike Rapoport : Palmer: it would be nice if risc-v would reuse as much as possible rather than copy it. Like e.g. the NUMA work that's aims to share with arm64 [18:33] Palmer Dabbelt : I think we're pretty good about making things generic [18:33] Paul Walmsley : Yeah, both Palmer and I try to encourage generic code sharing [18:34] Mike Rapoport : Agree, just don't stop on this :) [18:34] Paul Walmsley : We're not always perfect of course [18:34] Ian Forbes : no caching of get pid anymore [18:34] Palmer Dabbelt : well, maybe I'm derailing the discussion here, but I think we might be making things generic a bit too much [18:34] Palmer Dabbelt : I've got a few patch sets sitting around where we're making things generic that really only apply to RISC-V and arm64, for example [18:34] Christian Brauner : @florian and now systemd implements its own :) [18:35] Palmer Dabbelt : but ya, I don't think we're going to stop -- I hate code, so I don't want to own it ;) [18:35] Arnd Bergmann : @Peter @Mike: one problem with MIPS is that the main company went bust a while ago, so as far as I can tell nobody is paid to do interesting architecture work any more and all we have are a few platform maintainers and some volunteers [18:36] Paul Walmsley : In some ways it's easier to make something generic between a smaller number of architectures. Fewer acks needed, simpler testing, etc [18:36] Mike Rapoport : @brau_ner systemd seems to imlement everything ;-) [18:37] Paul Walmsley : But agree that it can be overdone [18:38] Palmer Dabbelt : so I guess there's really two sorts of generic things that go on: there's stuff where we're adding some new user-visible interface that's arch-specific (like the NUMA patches), and there it makes sense to have a small number of architectures that use the generic code -- usually we're copying arm64's interface, but the other architectures can't change over because they've already picked something different [18:39] Palmer Dabbelt : then there's these functions that are sort of architecture-specific, but happen to be the same in many places (looking at my branches, I guess I've got copy_oldmem_page and some devmem function) [18:40] Palmer Dabbelt : it feels like the second type should be applicable to a larger set of architectures than the first type [18:40] Will Deacon : The trick, as I see it, is to put the uncontroversial/slow rate of change logic into generic code, and then have the other parts implemented by the arch. i.e. don't make code generic just because you can, but rather but the part that would be copy-pasted anyway into generic code [18:41] Will Deacon : but that's really hard to figure out for new code, which doesn't have enough arch code to see which bits could sensibly be shared [18:41] Paul Walmsley : We had the same set of issues with some of the SoC-related code years ago, like the clock framework stuff [18:42] Mike Rapoport : will: right, but maybe posting some of the features wider that per-arch mailing list could help? [18:42] Michael Ellerman : @will Yeah. And doing it retrospectively is also hard work. [18:42] Mike Rapoport : I can't say everything relevant shows up even in linux-arch [18:43] Will Deacon : mpe: yeah, it's short-term vs long-term pain, I suppose [18:43] Will Deacon : and I agree that more or this should go to linux-arch [18:43] Arnd Bergmann : I'm unconvinced that the performance advantage of saving syscall overhead outweighs the cost of remapping per-cpu pages of the memory overhead of per-thread pages [18:44] Will Deacon : maybe if we had a CI bot on linux-arch that prioritised covering lots of architectures could be an inecntive? [18:44] Palmer Dabbelt : that'd be really great for me [18:44] Mark Brown : A CI bot doing what exactly? [18:44] Will Deacon : qemu boots on all architectures that we and qemu support, with results within a day? [18:44] Paul Walmsley : It's testing that's the real issue [18:44] Mark Brown : Is build and boot enough? [18:45] Paul Walmsley : Of the specific feature [18:45] Mark Brown : Or would LTP be enough. [18:45] Mark Brown : /me nods Paul [18:45] Paul Walmsley : And realistically it will need to be on hardware to be useful, in many cases [18:46] Mike Rapoport : I've misread the time, it's 5 minutes now [18:46] Mickaël Salaün : may be used as inspiration: https://fuchsia.dev/fuchsia-src/concepts/kernel/vdso [18:48] H. Peter Anvin : That inherently means that the vdso cannot be used across processes like it is now [18:49] Carlos O'Donell : Why not? TP + offset can be the same for all proceses? [18:49] Mathieu Desnoyers : If we make rseq extensible, many of the vDSO use-cases could be done through rseq instead [18:49] Mathieu Desnoyers : e..g current cpu id, thread id, numa node id... [18:49] Carlos O'Donell : @Mathieu Desnoyer, It *reduces* the use cases, but may not eliminate them. [18:49] Mathieu Desnoyers : @Carlos of course, e.g. reading current time [18:50] Rasmus Villemoes : exactly. Have one read-only page per thread populated by the kernel with the uid, euid, current-cpu etc. stuff, that only needs updating when those things change. And another page for the rseq and robust futex stuff and similar. Have clone grow a flag to say "use the first two pages of the stack for those purposes" [18:50] Carlos O'Donell : And other libc's (musl). [18:51] Mathieu Desnoyers : @Rasmus: the uid, euid, etc can be put into an extended struct rseq [18:51] Mathieu Desnoyers : we already have the current cpu number there [18:52] Mathieu Desnoyers : It does not even need to be a full page if it's allocated by user-space e.g. in a TLS and registered to the kernel [18:52] Rasmus Villemoes : yeah, it can all go in one page that's also writable by userspace, if one doesn't care about userspace being able to garble the euid etc. fields [18:52] Arnd Bergmann : @Will: qemu actually supports 17 of our architectures according to my (possibly outdated) list at https://docs.google.com/spreadsheets/d/1QxMvW5jpVG2jb4RM9CQQl27-wVpNYOa-_3K2RVKifb0/ [18:53] Mathieu Desnoyers : @Rasmus: yeah, the kernel should not care if userspace decides to corrupt it [18:53] Arnd Bergmann : the only surprising omissions are arc, ia64, csky and nds32 (need to recheck those) [18:53] Mathieu Desnoyers : that would reduce the number of pages (and TLB entries) required per thread for those [18:55] Rasmus Villemoes : no, I'm only a little worried somebody might have some check for "sorry, I won't run this as root" or "must be root" that could be fooled that way [18:55] Arnd Bergmann : https://git.zx2c4.com/wireguard-linux/tree/tools/testing/selftests/wireguard/qemu/arch has some selftest infrastructure for at least six architectures (plus some variants for endianess) [18:55] Vineet Gupta : @Arnd, we do have qemu port but it needs a bit of polishing before upstreaming [18:55] Arnd Bergmann : @Vineet ok, good to hear [18:56] Arnd Bergmann : @Vineet: do you also have a musl-libc port? That is also missing on ARC according to my list [18:56] Mike Rapoport : there's alsu Guenter's buildbot: http://server.roeck-us.net:8010/ [18:57] Vineet Gupta : Nope we don't have that at all [18:57] Mike Rapoport : @vineet I still cannot unsubscribe from synopsis spam after downloading nsim ;-) [18:58] Arnd Bergmann : @Vineet: a musl port is generally a fairly simple thing to do, especially compared to a glibc port, might be useful to look into that, not just in the light of automated testing using a simple user space [18:59] Peter Zijlstra : I'm getting ICE-1007 or something and no audio connection [18:59] Vivek Goyal : @Peter same here [18:59] Bharat Bhushan : Same here [19:00] Marc Zyngier : I managed to login in "listen only" mode, but not sure if I'm getting any audio. it's all very quiet. [19:00] Rasmus Villemoes : it would be nice if robust futex list, rseq, could be put in some contiguous region together with all the euid, pid, tid etc., with the kernel promising to keep the fields updated. Then nobody needs a hacky cache to get fast getpid(). [19:00] Russell King : I just reconnected - my FF seems to be becoming very hessitant... and still is after a restart. [19:00] Marc Zyngier : I do, thanks! [19:00] Vineet Gupta : @Arnd, ok will do [19:01] Bharat Bhushan : Joined in Audio mode but do not hear anything [19:01] Arnd Bergmann : @Bharat: you can try the youtube livestream as a fallback [19:02] Vineet Gupta : @Mike, I'm sorry, those things are above my pay grade ;-) But qemu is coming along fine now [19:02] Mike Rapoport : @vineet no problem :) [19:02] Kees Cook : yeah, no audio here either. [19:02] Jonathan Corbet : There appears to be some weirdness on this server... [19:03] Axel Rasmussen : It's working for me, maybe refreshing / rejoining will help? [19:03] Mike Rapoport : tglx: you can use whiteboard if you'd like to [19:04] Jonathan Corbet : OK, finally started working for me again. Strange. [19:09] Vineet Gupta : what is ABI specific in the TIF loop [19:09] Vineet Gupta : except saving regs maybe [19:11] Vineet Gupta : @MArk thats exactly what we do on ARC too - we save piece meal state [19:14] Russell King : I'm no longer conversant enough with the 32-bit ARM entry code to comment on whether we would switch over to this. [19:15] Russell King : Also, this is the first I've heard about this effort... [19:15] Kees Cook : The seccomp selftests appear to have a reasonable level of entry testing (with regard to ptrace and seccomp at least) [19:16] Mike Rapoport : rmk: are you subscribed to linux-arch? [19:16] Russell King : I used to be, but when it became linux-kernel v2 and had tonnes of traffic on it, I dropped off it. [19:16] Peter Zijlstra : @Kees I was trying to find those seccomp selftests the other dya, I couldn't find because there's only 'benchmark' and 'bpf' and I wasn't really interested in either ;-) [19:17] Kees Cook : @Peter bpf is what you want. [19:17] Kees Cook : @Peter it's likely a bit misnamed at this point [19:17] Peter Zijlstra : @Kees, fair enough [19:17] Kees Cook : since it does a bunch of ptrace tests too and all the seccomp behaviors [19:17] Christian Brauner : seccomp_bpf.c :) [19:18] Kees Cook : I will rename it to seccomp.c ;) [19:18] Christian Brauner : seccomp_ebpf.c? [19:18] Christian Brauner : /me ducks [19:18] Kees Cook : /me glares [19:18] Josh Poimboeuf : arm64 will have objtool one of these days [19:18] Russell King : Mike: I believe linux-arch was originally setup to be a way of notifying arch maintainers about stuff - it wasn't even a mailing list initially. It then devolved into a general discussion mailing list, and I basically didn't have the ability to track it anymore. [19:19] Mike Rapoport : rmk: these days it's lower volume than lAkml [19:22] Russell King : mike: there's also the issue that I don't actually do very much for 32-bit arm any more... [19:22] Mike Rapoport : :) [19:23] Drew Fustini : I miss the in person because Arnd always has tiny Ritter Sport treats :) [19:24] Ronen Friedman : you're complaining? I had to cook my own meal! [19:24] Nick Desaulniers : Linus, any chance you'll be writing follow up blog posts about arm64? [19:24] Russell King : Nice close-up of Linus' fingernails there! [19:25] Linus Walleij : Russell: I try to increase my ARm32 core kernel contributions, but it's terse. [19:25] Nick Desaulniers : Is that the dell xps with the webcam in the bottom left of the bezel? [19:28] Guo Ren : how copy_from/to_user performance? [19:29] Drew Fustini : I've been enjoying the people.kernel.org posts! [19:30] Geert Uytterhoeven : Looks good for m68k (and SPARC, I guess) [19:31] Russell King : From what I remember seeing on lakml, yes, there is an impact on user accesses [19:31] Mike Rapoport : @all please help with the shared notes [19:32] Rob Herring : Calxeda needed this about 8 years ago. :) [19:32] Mike Rapoport : Geert: do you have m68k machine with that much memory? [19:32] Geert Uytterhoeven : and RZ/G1, as used by CiP [19:32] Palmer Dabbelt : in theory rv32 has 34-bit physical addresses -- but I think we're going to cross our fingers and hope people don't do that ;) [19:33] Geert Uytterhoeven : Mike: nah, I only have 12 MiB (FastRAM) in my Amiga [19:33] Geert Uytterhoeven : But an Amiga can have 3.75 GiB, in theory [19:34] Mike Rapoport : Back to the question of obsoleting the hardware, are those amigas around? ;-) [19:34] Peter Zijlstra : Didn't this Torvalds character hate 4G:4G with a passion? [19:35] Jamie Lokier : Nvidia was hated more in the end :-) [19:35] Geert Uytterhoeven : mike: the largest one I know of is an Amiga with a single BigRamPlus (256 MiB) expansion card. [19:37] Mike Rapoport : Geert: I think m68k never had HIGHMEM to begin with, right? [19:38] Geert Uytterhoeven : mike: no, we never had highmem. [19:39] Masami Hiramatsu : can we remap the user pages to kernel space and copy it? [19:39] Will Deacon : aspects of this are similar to the kpti implementation for arm64, which allocates two ASIDs per task, in order to reduce/avoid TLB invalidation required by uaccess [19:40] Geert Uytterhoeven : In theory you could have more than 4 GiB of RAM, as the address space selector ("function code") bits are available on external pins. So you can have 4 GiB of kernel memory, and 4 separate GiB of user memory. [19:44] Russell King : Which we already support (optimised 1GB) [19:44] Palmer Dabbelt : I agree [19:45] Drew Fustini : @palmer - do you think people will run Linux on RV32? [19:45] Palmer Dabbelt : I think it'll show up [19:45] Mike Rapoport : @drew there is a system with 8M of ram [19:45] Paul Walmsley : They already do :-) [19:45] Mike Rapoport : Damien really was into it [19:45] Drew Fustini : oh yeah, the k210 [19:46] Paul Walmsley : See all the LiteX/VeXRISCV etc [19:46] Palmer Dabbelt : well, I guess, I think real hardware will show up [19:46] Jason Sidebottom : That's RV64 though [19:46] Drew Fustini : it works but is kinda of a toy [19:46] Drew Fustini : yes, LiteX is great... I've only seen boards with 1GB so far [19:46] Drew Fustini : DDR [19:46] Paul Walmsley : One can just put a 4GiB DIMM in a VC707 or something [19:46] Drew Fustini : Jsaon: good point, k210 is rv64 [19:47] Drew Fustini : I was thinking more if there would be a linux capable RV32 ASIC... seeems like an odd choice [19:48] Palmer Dabbelt : I wouldn't be surprised if there end up being 32-bit Linux capable ASICs [19:48] Jamie Lokier : Drew: I think it very likely indeed people will run Linux on RV32. If for no other reason than RV64 is larger in an FPGA. [19:50] Geert Uytterhoeven : and in an ASIC [19:51] Paul Walmsley : https://github.com/litex-hub/linux-on-litex-vexriscv [19:51] Drew Fustini : yes, I'm using that [19:52] Jamie Lokier : Geert: Yes, but space tends to be less tight in ASIC. [19:52] Drew Fustini : I was thinking more about large RAMand RV32 [19:52] Jason Sidebottom : I think the general rule appies: if it can run Linux, people will run Linux on it [19:52] Drew Fustini : i guess it would be weird to choose RV32 instead of RV64 and then have more than 1GB ram [19:53] Jason Sidebottom : Yeah, I don't expect that [19:53] Vineet Gupta : Mmike, I finally did get around to your sparseme patch for ARC - running into a issues even before that when enabling highmem - lets continue discussion on ml on that thread [19:53] Drew Fustini : only TI does such things :) [19:53] Drew Fustini : /me looks at keystone [19:53] Arnd Bergmann : @Jamie: if you are running RV32 because of FPGA space constraints, you are again unlikely to have a DDR4 memory interface, so you are back to the size constraints of DDR3, with no more than 1GB or 2GB at most [19:53] Arnd Bergmann : possibly much smaller if you are on DDR2 [19:53] Drew Fustini : arnd: thanks for the insights [19:54] Jamie Lokier : There are always ways to multiplex memory out there. Long history of it. [19:55] Paul Walmsley : Folks are still using 4GiB SODIMMS with DDR3. [19:55] Jamie Lokier : Done it myself by hand, literally piggy-backing memory chips on other memory chips... Doubled the RAM in my Atari ST that way :-) [19:55] Paul Walmsley : $22 on Amazon [19:56] Palmer Dabbelt : any DIMM controller will vastly out-size cores where rv32 vs rv64 matters [19:56] Palmer Dabbelt : I guess maybe not DDR2 [19:56] Jamie Lokier : Surely someone makes an external DIMM controller, or an FPGA with integrated DIMM controller? [19:57] Palmer Dabbelt : ya, we run on a bunch of old Xilinx boards that have 32-bit hard memory controllers and support up to 4GiB DIMMs [19:57] Jonathan Cameron : Maybe Linux on some insane accelerator type design. Big FPGA but a very large number of cores? [19:57] Jonathan Cameron : or bit asic for that matter. [19:58] Jonathan Cameron : (on basis people run Linux on anything that will run Linux :) [19:58] Palmer Dabbelt : well, I think the real question is: would anyone build that hardware? [19:58] Jason Sidebottom : If you're going for an accelerator, you tend to have many dumb cores with local memory. They aren't going to run linux. [19:58] Mark Rutland : with 8+ cpus you end up needing GICv3+, which in practice means 64-bit [19:58] Mark Rutland : (madness otherwise) [19:59] Palmer Dabbelt : if rv32 hardware with a bunch of memory shows up then we'll figure out some way to deal with it, I just think that's an unlikely design point [19:59] Robin Murphy : Even at the low end of the TV box market, 4GB of (LP)DDR3 is pretty common - one of mine has that in a single chip [19:59] Jonathan Cameron : GICv3 with RV? :) [20:00] Arnd Bergmann : @Robin on a 32-bit core? [20:00] Mark Rutland : Reading bias ;) [20:01] Geert Uytterhoeven : yes [20:01] Jason Sidebottom : Loud and clear [20:01] Palmer Dabbelt : well, we do need a new interrupt controller... ;) [20:01] Will Deacon : I recommend GICv3 [20:01] Will Deacon : (this is what's known as sabotage) [20:01] Paul Walmsley : lol [20:01] Jonathan Cameron : :) [20:02] Jonathan Cameron : That would be a good licensing argument :) [20:02] Geert Uytterhoeven : yes [20:02] Damian Tometzki : yes [20:02] Jason Sidebottom : I had to restart my browser to connect camera at one point. [20:02] Pavel Pisa : I see slides [20:02] Damian Tometzki : too [20:04] Marc Zyngier : a good interrupt controller is a dead interrupt controller. and GICv3 is not dead enough. [20:04] Robin Murphy : @Arnd not for TV boxes admittedly (32-bit is only for the ultra-low end now), but compound that with the fact that i.MX6 is very much alive, so non-LPAE 4GB looks to still a thing for industrial modules available right now with long-term support/availability promises [20:06] Arnd Bergmann : @Robin I talked a lot of embedded system vendors during this year's embeddedWorld. Almost everyone had some imx6q machine, many had 2GB configurations, but almost none had ever sold a 4GB one even if they offered one [20:07] Robin Murphy : good to know :) [20:08] Arnd Bergmann : all of the newer imx6 variants support at most 2GB since they have a narrower memory bus [20:09] Arnd Bergmann : The problem with 4GB DDR3 is that you either need four 8Gbit chips at a prohibitive cost, or you need eight 4Gbit chips, which makes an awfully complex board design if you can do it [20:10] Pavel Pisa : I have workedn on u-boot support fr solidrun module build for one company with 4 gigs memory [20:10] Paul Walmsley : One can't necessarily choose the DDR controller that is used if one is not designing one's own chip :-) [20:11] Jamie Lokier : IA-64 had support in Qemu, though it was removed a few years ago. So it has an _old_ simulator if that helps. [20:12] Arnd Bergmann : @Pavel, yes the 4GB version of the cubox-i is one of the known exceptions. They were discontinued after a very short time though, only the 2GB version was sold for most of the time [20:13] Russell King : 4GB on imx6 causes problems for the GPU. [20:13] Arnd Bergmann : The Novena Laptop is another imx6q with a 4GB option, but that also shipped in very small quantities [20:13] Rob Herring : @Arnd If the SoC vendors didn't test and/or validate with 8 chips, it's unlikely to work regardless of board design. [20:19] Pavel Pisa : Some off topic question for imx6, is there solution for PCIe reset HW bug. It seems that PCIe device reset lock whole chip and there is no way to recover PCIe link. I have heard that confirmation of PCIe bug requires NDA from NXP which prevent to share knowledge. [20:19] Will Deacon : Be nice to have the CMA initialisation done in core code too...That would stop the trickle of patches reordering our function calls in setup_arch() to get the implicit dependencies right. [20:19] Jonathan Cameron : Agreed with Will. That's a mess. [20:20] Michael Ellerman : The end state is what we have on PPC where boot is basically finished before setup_arch(). [20:21] Will Deacon : mpe: Is that because core code does everything you need, or because you have arch code that runs super early? [20:22] Michael Ellerman : The latter. We do lots of setup really early. [20:22] Will Deacon : Ah, so it doesn't necessarily solve the implicit dependencies where core code is concerned then [20:23] Michael Ellerman : No I meant it as an example of what not to do :) [20:24] Will Deacon : oh, haha, then I shall stop reading it in search of inspiration! [20:24] Russell King : lol [20:24] Jonathan Cameron : snort [20:24] Michael Ellerman : The are Reasons it's like that of course, but yeah run away :) [20:27] Jonathan Cameron : There are some parts of the numa code that are near identical across x86 and arm64, but other are nasty. [20:27] Jonathan Cameron : So it may be a partial sharing is possible. [20:28] Jonathan Cameron : (microphone died in last few mins...) [20:28] Russell King : Thank you for this. [20:28] Will Deacon : I know Dan Williams was running into differences wrt NUMA and memblock, but I don't recall the details off hand [20:28] atish patra : yeah. We may have arch specific hooks where arm64 & x86 can have specific bits [20:29] Jonathan Cameron : Even then the different underlying representation is horribly different in places (like Mike just mentioned) [20:29] Mike Rapoport : Jonathan: e820 rules ;-) [20:29] Jonathan Cameron : But let's do the low hanging fruit like the numa distance representations... Then we can see what's left. [20:30] Jonathan Cameron : e820 gives me a headache every time... [20:30] Jonathan Cameron : may just be I don't know it as well :) [20:32] Michael Ellerman : Good turn out I think, I wasn't sure how many folks would be interested. [20:32] atish patra : yes. NUMA distance patch can be a starting point [20:32] Jonathan Cameron : It's been like a real plumbers with slightly less actual running. Somehow there are always clashes! [20:36] Arnd Bergmann : this is a little more than I was expecting for "one more question"... [20:36] Mike Rapoport : :) [20:38] Geert Uytterhoeven : One more poll? ;-) [20:38] James Bottomley : Should we have a poll to see if we want another poll? [20:40] Geert Uytterhoeven : The polling system seems to work well. Should tell tbird about it, for a closing game ;-) [20:41] Geert Uytterhoeven : FWIW, the u8 cmpxchg was triggered by a "bad" driver patch [20:41] Helge Deller : Paul, I agree! [20:41] Arnd Bergmann : who wants another poll? [20:41] Geert Uytterhoeven : Well, at least we're gonna have it on all archs soon ;-) [20:42] Geert Uytterhoeven : depends on CNFIG_u8CMPXCHG [20:44] Geert Uytterhoeven : You need something for SMP, indeed [20:46] Geert Uytterhoeven : thx all, and CU tomorrow!! [20:46] Michael Ellerman : It would be nice if we didn't have to support cmpxchg on u8 etc. [20:47] Paul Walmsley : Agreed [20:47] Drew Fustini : it's still alive until the last file handle is closed :) [20:47] Paul Walmsley : Probably need to look at the qspinlock issue that Mark mentioned though [20:48] Geert Uytterhoeven : mpe: https://lore.kernel.org/lkml/CAMuHMdUGu+pqZs5YoiBnZ2j7Yx86VDU9oKr4C15c1Jc9GjQuNA@mail.gmail.com/ [20:48] Paul Walmsley : Still if architectures don't support efficient sub-word size xchg(), then qspinlocks seem pointless :-) [20:51] Pavel Pisa : Good bye.