Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp122330imm; Thu, 26 Jul 2018 15:13:03 -0700 (PDT) X-Google-Smtp-Source: AAOMgpf7vwZUq1kP972J5WSSxZ9k7pf/6wE2qRF/4TXdz9Jgfeh2d1MptdYMkQLfxKYsY/oURRTw X-Received: by 2002:a17:902:209:: with SMTP id 9-v6mr3573934plc.270.1532643183531; Thu, 26 Jul 2018 15:13:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532643183; cv=none; d=google.com; s=arc-20160816; b=H+h900ULU7ptjHUNWVtdPaBu8kjk/Unn6vNUa78A1ljftneKPKdqADPUDvF+U/2Ulz SpwvY2IeIYXOwJ4UWOHUQdjraNX9zkqSwp4ouurbGVyXM+3x4ukGdlkbrYj7HDR5FFON EtyJZI8N3v9Syev4UZVVZbTimp9CkZFof5FwGagCpHwsuVfd6ffp2EitDW1iLQdH1D3/ r7cu5u7+7Us0mZVAw3r+x7nAKTjEUFXSiej/t054BE9+GgeaD/ha4dJ90Lgud+9mlcek R7VENcouypJHrhSAFAaMofhRA0fgqOQBl2wZFzS0zhtEHPiAPjOlMhMWld68XOzgt+Vf 9big== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=vQaJ7N0VirR3VdZAPVkqc8JhTNEn/DONZo+YdzZUuQc=; b=pLxV6rxLBEyg2xUj06GIEuP0J9R9buOm/mhox7s4k+iM4+4SNC0rCrNyqXc31+sEQC kJLlgtoVgsk+mc3zHir8jRnEiE1VUQEBpIaNPIcuxOmEtpycwFMmMY+6YIXqPYF0+Zh6 iviaF0jCVNxExed65z9HQnr2FbrMTy1OrkzsX1HwZbx/0q22BdKq343uYhVxRL/suV9J TNFbjOpwgX35MaHQt5XvS4PrXOpcVIn7WGgWlvaV0DrgsbmR83+uy3sZ9C/xg9jbb30f 8CtIt/2lkXAWq0tZcefCA0xJenznUs9T6T+7XEyr9vtMvvLpB3RNmv0b1Xs+t0va1Q3w T++g== ARC-Authentication-Results: i=1; mx.google.com; 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 y62-v6si2400820pfd.254.2018.07.26.15.12.48; Thu, 26 Jul 2018 15:13: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; 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 S1731757AbeGZXaI (ORCPT + 99 others); Thu, 26 Jul 2018 19:30:08 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:50586 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731479AbeGZXaI (ORCPT ); Thu, 26 Jul 2018 19:30:08 -0400 Received: from akpm3.svl.corp.google.com (unknown [104.133.9.92]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id F2EAFC9B; Thu, 26 Jul 2018 22:11:19 +0000 (UTC) Date: Thu, 26 Jul 2018 15:11:18 -0700 From: Andrew Morton To: "zhaowuyun@wingtech.com" Cc: "Michal Hocko" , mgorman , minchan , vinmenon , hannes , "hillf.zj" , linux-mm , linux-kernel , "Hugh Dickins" Subject: Re: [PATCH] [PATCH] mm: disable preemption before swapcache_free Message-Id: <20180726151118.db0cf8016e79bed849e549f9@linux-foundation.org> In-Reply-To: <20180726150323057627100@wingtech.com> References: <2018072514375722198958@wingtech.com> <20180725141643.6d9ba86a9698bc2580836618@linux-foundation.org> <2018072610214038358990@wingtech.com> <20180726060640.GQ28386@dhcp22.suse.cz> <20180726150323057627100@wingtech.com> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 26 Jul 2018 15:03:23 +0800 "zhaowuyun@wingtech.com" wrote: > >On Thu 26-07-18 10:21:40, zhaowuyun@wingtech.com wrote: > >[...] > >> Our project really needs a fix to this issue > > > >Could you be more specific why? My understanding is that RT tasks > >usually have all the memory mlocked otherwise all the real time > >expectations are gone already. > >-- > >Michal Hocko > >SUSE Labs > > > The RT thread is created by a process with normal priority, and the process was sleep, > then some task needs the RT thread to do something, so the process create this thread, and set it to RT policy. > I think that is the reason why RT task would read the swap. A simpler bandaid might be to replace the cond_resched() with msleep(1).