Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp4007048yba; Tue, 7 May 2019 10:32:03 -0700 (PDT) X-Google-Smtp-Source: APXvYqyR0WlfJBxwMCQ5UHBghzdCz5aZrk6/odfg4ntX+UwSJPmY55pNgeKWkZKeo0mZXN/lfaVx X-Received: by 2002:a17:902:446:: with SMTP id 64mr36143612ple.322.1557250323691; Tue, 07 May 2019 10:32:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557250323; cv=none; d=google.com; s=arc-20160816; b=b+eTz5AmvG5gk9QTcOjUBUK4IafBxBFRvSU9McLFokuTFJR59j5U0nW6HNgeyHwB/V 9+r0ALkIHXM3FMy0TP7OVC6HKHfugytjAGbaQUjeJuSIa0HBrH8OOWYg8ZTEDpVa+KV1 YgRIr9p6sU70CIBNBF1wddgZMFVcE0jvINQhcx0Z6f0/vVKbOdyiCc8v2jm7J+i8Xzn6 U5JEbHIq0RMyyhk5Ao+E3gh5WE8dgs+zPvtIT8OzFQOGtzRqs5htWkDfLbZ6/Wnq3imf xOENwgRkk/pRG2mktB9ZS2IPsWUbMPuPeADeD2OOLdjKYS9uPwRJq1isKxdvQGHLXHP9 ccGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=QgG44jb4fJDoD6Rh0WX/xkP1elw2in9+IHLQrR9ghTA=; b=xE0nddKYglnuU7JmAlcog4HzPc4KdBuABFyR4DxmbK9b/rrHiXCoDFu3rdq+yjXAan byH4fDdDM8buPLT0264uN/V16LLBC+PGwFePJ2IpDVfI7bujapo/FRlx46e4FMXCrpde Cg82s2kDh9v957BCKx8Xw7MRo/las+Wqqx80WdkufNBJ4QVX9dLMgQTLsA1jUISjN9Cw PsqeypnnaV0aqPzcSBPX26rtk8ac9/OA59IPCs5orJ03fm/tn/U2HQnPl9OOz22sSHpD w6SeCLH9pkKLM78dl8AWeaiIEbmE0bPiCRmapucm3bWFuMdNNEovdcUTcVUwqUBPMv06 4F1g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=X69pWunF; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 30si20269952plc.8.2019.05.07.10.31.47; Tue, 07 May 2019 10:32:03 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=X69pWunF; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727417AbfEGR3o (ORCPT + 99 others); Tue, 7 May 2019 13:29:44 -0400 Received: from mail.kernel.org ([198.145.29.99]:39546 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726756AbfEGR3o (ORCPT ); Tue, 7 May 2019 13:29:44 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CDFC9205ED; Tue, 7 May 2019 17:29:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1557250183; bh=0aJ6ctT9vRN+sTWk16Y0kR/0wZNkZvMg4FJNEQtB+p4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=X69pWunFdt3abRor30eAi6ii8e0h5YWRT265TXQ35VyTi3237oX/jgxrmWxHMDzrn jWcC3oUU67MGkRXnhy+uK/D0yND+RsTKHyAZqgjvh1anuZd8OMCMwHp6Ew+oHmwYRj q6lrXTdH17oLXqhF6mYfNJwdkR7vBAeIWptDiI0o= Date: Tue, 7 May 2019 19:29:41 +0200 From: Greg Kroah-Hartman To: Sultan Alsawaf Cc: Christian Brauner , "open list:ANDROID DRIVERS" , Daniel Colascione , kernel-team , Todd Kjos , Kees Cook , Peter Zijlstra , LKML , Tim Murray , Michal Hocko , Suren Baghdasaryan , linux-mm , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Ingo Molnar , Steven Rostedt , Oleg Nesterov , Joel Fernandes , Andy Lutomirski , Martijn Coenen Subject: Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android Message-ID: <20190507172940.GA6835@kroah.com> References: <20190319231020.tdcttojlbmx57gke@brauner.io> <20190320015249.GC129907@google.com> <20190507021622.GA27300@sultan-box.localdomain> <20190507070430.GA24150@kroah.com> <20190507072721.GA4364@sultan-box.localdomain> <20190507074334.GB26478@kroah.com> <20190507081236.GA1531@sultan-box.localdomain> <20190507105826.oi6vah6x5brt257h@brauner.io> <20190507171711.GB12201@sultan-box.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190507171711.GB12201@sultan-box.localdomain> User-Agent: Mutt/1.11.4 (2019-03-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 07, 2019 at 10:17:11AM -0700, Sultan Alsawaf wrote: > On Tue, May 07, 2019 at 01:09:21PM +0200, Greg Kroah-Hartman wrote: > > > 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 > > > 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? > > > > "almost no"? Again, Android Go is doing that, right? > > I'd check for myself, but I can't seem to find kernel source for an Android Go > device... > > This seems more confusing though. Why would the ultra-low-end devices use LMKD > while other devices use the broken lowmemorykiller driver? It's probably because the Android Go devices got a lot more "help" from people at Google than did the other devices you are looking at. Also, despite the older kernel version, they are probably running a newer version of Android userspace, specially tuned just for lower memory devices. So those 3.18.y based Android Go devices are newer than the 4.4.y based "full Android" devices on the market, and even some 4.9.y based devices. Yes, it is strange :) > > > Qualcomm still uses lowmemorykiller.c [1] on the Snapdragon 845. > > > > Qualcomm should never be used as an example of a company that has any > > idea of what to do in their kernel :) > > Agreed, but nearly all OEMs that use Qualcomm chipsets roll with Qualcomm's > kernel decisions, so Qualcomm has a bit of influence here. Yes, because almost no OEM wants to mess with their kernel, they just take QCOM's kernel and run with it. But don't take that for some sort of "best design practice" summary at all. > > > If PSI were backported to 4.4, or even 3.18, would it really be used? > > > > Why wouldn't it, if it worked properly? > > For the same mysterious reason that Qualcomm and others cling to > lowmemorykiller, I presume. This is part of what's been confusing me for quite > some time... QCOM's 4.4.y based kernel work was done 3-4 years ago, if not older. They didn't know that this was not the "right way" to do things. The Google developers have been working for the past few years to do it correct, but they can not go back in time to change old repos, sorry. Now that I understand you just want to work on your local device, that makes more sense. But I think you will have a better result trying to do a 4.4 backport of PSI combined with the userspace stuff, than to try to worry about your driver in 5.2 or newer. Or you can forward-port your kernel to 4.9, or better yet, 4.14. That would probably be a much better thing to do overall as 4.4 is really old now. Good luck! greg k-h