Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752787AbdCFJJM (ORCPT ); Mon, 6 Mar 2017 04:09:12 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:59516 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752708AbdCFJJG (ORCPT ); Mon, 6 Mar 2017 04:09:06 -0500 Subject: Re: [RFC 01/11] mm: use SWAP_SUCCESS instead of 0 To: Minchan Kim , Anshuman Khandual References: <1488436765-32350-1-git-send-email-minchan@kernel.org> <1488436765-32350-2-git-send-email-minchan@kernel.org> <20170303030158.GD3503@bbox> Cc: Andrew Morton , kernel-team@lge.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Johannes Weiner , Michal Hocko , "Kirill A . Shutemov" From: Anshuman Khandual Date: Mon, 6 Mar 2017 14:37:40 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170303030158.GD3503@bbox> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 17030609-0012-0000-0000-0000021A2B7D X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17030609-0013-0000-0000-000007203060 Message-Id: <33a8d76e-dbeb-bcf1-5024-5e780b81bef6@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-06_08:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703060078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 769 Lines: 17 On 03/03/2017 08:31 AM, Minchan Kim wrote: > On Thu, Mar 02, 2017 at 07:57:10PM +0530, Anshuman Khandual wrote: >> On 03/02/2017 12:09 PM, Minchan Kim wrote: >>> SWAP_SUCCESS defined value 0 can be changed always so don't rely on >>> it. Instead, use explict macro. >> >> Right. But should not we move the changes to the callers last in the >> patch series after doing the cleanup to the try_to_unmap() function >> as intended first. > > I don't understand what you are pointing out. Could you elaborate it > a bit? I was just referring to the order of this patch in the series and thinking if it would have been better if this patch would be at a later stage in the series. But I guess its okay as we are any way dropping off SWAP_FAIL, SWAP_SUCCESS etc in the end.