On Tue, May 07, 2019 at 01:12:36AM -0700, Sultan Alsawaf wrote: > On Tue, May 07, 2019 at 09:43:34AM +0200, Greg Kroah-Hartman wrote: > > Given that any "new" android device that gets shipped "soon" should be > > using 4.9.y or newer, is this a real issue? > > It's certainly a real issue for those who can't buy brand new Android devices > without software bugs every six months :) > > > And if it is, I'm sure that asking for those patches to be backported to > > 4.4.y would be just fine, have you asked? > > > > Note that I know of Android Go devices, running 3.18.y kernels, do NOT > > use the in-kernel memory killer, but instead use the userspace solution > > today. So trying to get another in-kernel memory killer solution added > > anywhere seems quite odd. > > It's even more odd that although a userspace solution is touted as the proper > way to go on LKML, almost no Android OEMs are using it, and even in that > commit
That's probably because without proper kernel changes this is rather tricky to use safely (see below). > I linked in the previous message, Google made a rather large set of > modifications to the supposedly-defunct lowmemorykiller.c not one month ago. > What's going on? > > Qualcomm still uses lowmemorykiller.c [1] on the Snapdragon 845. If PSI were > backported to 4.4, or even 3.18, would it really be used? I don't really > understand the aversion to an in-kernel memory killer on LKML despite the rest > of the industry's attraction to it. Perhaps there's some inherently great cost > in using the userspace solution that I'm unaware of? > > Regardless, even if PSI were backported, a full-fledged LMKD using it has yet > to > be made, so it wouldn't be of much use now. This is work that is ongoing and requires kernel changes to make it feasible. One of the things that I have been working on for quite a while is the whole file descriptor for processes thing that is important for LMKD (Even though I never thought about this use-case when I started pitching this.). Joel and Daniel have joined in and are working on making LMKD possible. What I find odd is that every couple of weeks different solutions to the low memory problem are pitched. There is simple_lkml, there is LMKD, and there was a patchset that wanted to speed up memory reclaim at process kill-time by adding a new flag to the new pidfd_send_signal() syscall. That all seems - though related - rather uncoordinated. Now granted, coordinated is usually not how kernel development necessarily works but it would probably be good to have some sort of direction and from what I have seen LMKD seems to be the most coordinated effort. But that might just be my impression. Christian _______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
