From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161326AbbBDTYw (ORCPT ); Wed, 4 Feb 2015 14:24:52 -0500 Received: from mail-la0-f43.google.com ([209.85.215.43]:35307 "EHLO mail-la0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752723AbbBDTYt convert rfc822-to-8bit (ORCPT ); Wed, 4 Feb 2015 14:24:49 -0500 MIME-Version: 1.0 Reply-To: mtk.manpages@gmail.com In-Reply-To: <54D2508A.9030804@suse.cz> References: <20150202165525.GM2395@suse.de> <54CFF8AC.6010102@intel.com> <54D08483.40209@suse.cz> <20150203105301.GC14259@node.dhcp.inet.fi> <54D0B43D.8000209@suse.cz> <54D0F56A.9050003@gmail.com> <54D22298.3040504@suse.cz> <54D2508A.9030804@suse.cz> From: "Michael Kerrisk (man-pages)" Date: Wed, 4 Feb 2015 20:24:27 +0100 Message-ID: Subject: Re: MADV_DONTNEED semantics? Was: [RFC PATCH] mm: madvise: Ignore repeated MADV_DONTNEED hints To: Vlastimil Babka Cc: "Kirill A. Shutemov" , Dave Hansen , Mel Gorman , "linux-mm@kvack.org" , Minchan Kim , Andrew Morton , lkml , Linux API , linux-man , Hugh Dickins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4 February 2015 at 18:02, Vlastimil Babka wrote: > On 02/04/2015 03:00 PM, Michael Kerrisk (man-pages) wrote: >> >> Hello Vlastimil, >> >> On 4 February 2015 at 14:46, Vlastimil Babka wrote: >>>>> >>>>> - that covers mlocking ok, not sure if the rest fits the "shared pages" >>>>> case >>>>> though. I dont see any check for other kinds of shared pages in the >>>>> code. >>>> >>>> >>>> Agreed. "shared" here seems confused. I've removed it. And I've >>>> added mention of "Huge TLB pages" for this error. >>> >>> >>> Thanks. >> >> >> I also added those cases for MADV_REMOVE, BTW. > > > Right. There's also the following for MADV_REMOVE that needs updating: > > "Currently, only shmfs/tmpfs supports this; other filesystems return with > the error ENOSYS." > > - it's not just shmem/tmpfs anymore. It should be best to refer to > fallocate(2) option FALLOC_FL_PUNCH_HOLE which seems to be (more) up to > date. > > - AFAICS it doesn't return ENOSYS but EOPNOTSUPP. Also neither error code is > listed in the ERRORS section. Yup, I recently added that as well, based on a patch from Jan Chaloupka. >>>>>>> - The word "will result" did sound as a guarantee at least to me. So >>>>>>> here it >>>>>>> could be changed to "may result (unless the advice is ignored)"? >>>>>> >>>>>> It's too late to fix documentation. Applications already depends on >>>>>> the >>>>>> beheviour. >>>>> >>>>> Right, so as long as they check for EINVAL, it should be safe. It >>>>> appears >>>>> that >>>>> jemalloc does. >>>> >>>> So, first a brief question: in the cases where the call does not error >>>> out, >>>> are we agreed that in the current implementation, MADV_DONTNEED will >>>> always result in zero-filled pages when the region is faulted back in >>>> (when we consider pages that are not backed by a file)? >>> >>> I'd agree at this point. >> >> Thanks for the confirmation. >> >>> Also we should probably mention anonymously shared pages (shmem). I think >>> they behave the same as file here. >> >> You mean tmpfs here, right? (I don't keep all of the synonyms straight.) > > shmem is tmpfs (that by itself would fit under "files" just fine), but also > sys V segments created by shmget(2) and also mappings created by mmap with > MAP_SHARED | MAP_ANONYMOUS. I'm not sure if there's a single manpage to > refer to the full list. So, how about this text: After a successful MADV_DONTNEED operation, the seman‐ tics of memory access in the specified region are changed: subsequent accesses of pages in the range will succeed, but will result in either reloading of the memory contents from the underlying mapped file (for shared file mappings, shared anonymous mappings, and shmem-based techniques such as System V shared memory segments) or zero-fill-on-demand pages for anonymous private mappings. Thanks, Michael From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael Kerrisk (man-pages)" Subject: Re: MADV_DONTNEED semantics? Was: [RFC PATCH] mm: madvise: Ignore repeated MADV_DONTNEED hints Date: Wed, 4 Feb 2015 20:24:27 +0100 Message-ID: References: <20150202165525.GM2395@suse.de> <54CFF8AC.6010102@intel.com> <54D08483.40209@suse.cz> <20150203105301.GC14259@node.dhcp.inet.fi> <54D0B43D.8000209@suse.cz> <54D0F56A.9050003@gmail.com> <54D22298.3040504@suse.cz> <54D2508A.9030804@suse.cz> Reply-To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <54D2508A.9030804-AlSwsSmVLrQ@public.gmane.org> Sender: linux-man-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Vlastimil Babka Cc: "Kirill A. Shutemov" , Dave Hansen , Mel Gorman , "linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org" , Minchan Kim , Andrew Morton , lkml , Linux API , linux-man , Hugh Dickins List-Id: linux-man@vger.kernel.org On 4 February 2015 at 18:02, Vlastimil Babka wrote: > On 02/04/2015 03:00 PM, Michael Kerrisk (man-pages) wrote: >> >> Hello Vlastimil, >> >> On 4 February 2015 at 14:46, Vlastimil Babka wrote: >>>>> >>>>> - that covers mlocking ok, not sure if the rest fits the "shared = pages" >>>>> case >>>>> though. I dont see any check for other kinds of shared pages in t= he >>>>> code. >>>> >>>> >>>> Agreed. "shared" here seems confused. I've removed it. And I've >>>> added mention of "Huge TLB pages" for this error. >>> >>> >>> Thanks. >> >> >> I also added those cases for MADV_REMOVE, BTW. > > > Right. There's also the following for MADV_REMOVE that needs updating= : > > "Currently, only shmfs/tmpfs supports this; other filesystems return = with > the error ENOSYS." > > - it's not just shmem/tmpfs anymore. It should be best to refer to > fallocate(2) option FALLOC_FL_PUNCH_HOLE which seems to be (more) up = to > date. > > - AFAICS it doesn't return ENOSYS but EOPNOTSUPP. Also neither error = code is > listed in the ERRORS section. Yup, I recently added that as well, based on a patch from Jan Chaloupka= =2E >>>>>>> - The word "will result" did sound as a guarantee at least to m= e. So >>>>>>> here it >>>>>>> could be changed to "may result (unless the advice is ignored)"= ? >>>>>> >>>>>> It's too late to fix documentation. Applications already depends= on >>>>>> the >>>>>> beheviour. >>>>> >>>>> Right, so as long as they check for EINVAL, it should be safe. It >>>>> appears >>>>> that >>>>> jemalloc does. >>>> >>>> So, first a brief question: in the cases where the call does not e= rror >>>> out, >>>> are we agreed that in the current implementation, MADV_DONTNEED wi= ll >>>> always result in zero-filled pages when the region is faulted back= in >>>> (when we consider pages that are not backed by a file)? >>> >>> I'd agree at this point. >> >> Thanks for the confirmation. >> >>> Also we should probably mention anonymously shared pages (shmem). I= think >>> they behave the same as file here. >> >> You mean tmpfs here, right? (I don't keep all of the synonyms straig= ht.) > > shmem is tmpfs (that by itself would fit under "files" just fine), bu= t also > sys V segments created by shmget(2) and also mappings created by mmap= with > MAP_SHARED | MAP_ANONYMOUS. I'm not sure if there's a single manpage = to > refer to the full list. So, how about this text: After a successful MADV_DONTNEED operation, the seman=E2=80= =90 tics of memory access in the specified region are changed: subsequent accesses of pages in the range will succeed, but will result in either reloading of the memory contents from the underlying mapped file (for shared file mappings, shared anonymous mappings, and shmem-based techniques such as System V shared memory segments) or zero-fill-on-demand pages for anonymous private mappings. Thanks, Michael -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by kanga.kvack.org (Postfix) with ESMTP id CB1F4900015 for ; Wed, 4 Feb 2015 14:24:49 -0500 (EST) Received: by mail-lb0-f178.google.com with SMTP id u10so3294259lbd.9 for ; Wed, 04 Feb 2015 11:24:49 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com. [2a00:1450:4010:c04::22d]) by mx.google.com with ESMTPS id w8si2224113lbb.25.2015.02.04.11.24.47 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Feb 2015 11:24:48 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id p9so3325380lbv.4 for ; Wed, 04 Feb 2015 11:24:47 -0800 (PST) MIME-Version: 1.0 Reply-To: mtk.manpages@gmail.com In-Reply-To: <54D2508A.9030804@suse.cz> References: <20150202165525.GM2395@suse.de> <54CFF8AC.6010102@intel.com> <54D08483.40209@suse.cz> <20150203105301.GC14259@node.dhcp.inet.fi> <54D0B43D.8000209@suse.cz> <54D0F56A.9050003@gmail.com> <54D22298.3040504@suse.cz> <54D2508A.9030804@suse.cz> From: "Michael Kerrisk (man-pages)" Date: Wed, 4 Feb 2015 20:24:27 +0100 Message-ID: Subject: Re: MADV_DONTNEED semantics? Was: [RFC PATCH] mm: madvise: Ignore repeated MADV_DONTNEED hints Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-linux-mm@kvack.org List-ID: To: Vlastimil Babka Cc: "Kirill A. Shutemov" , Dave Hansen , Mel Gorman , "linux-mm@kvack.org" , Minchan Kim , Andrew Morton , lkml , Linux API , linux-man , Hugh Dickins On 4 February 2015 at 18:02, Vlastimil Babka wrote: > On 02/04/2015 03:00 PM, Michael Kerrisk (man-pages) wrote: >> >> Hello Vlastimil, >> >> On 4 February 2015 at 14:46, Vlastimil Babka wrote: >>>>> >>>>> - that covers mlocking ok, not sure if the rest fits the "shared page= s" >>>>> case >>>>> though. I dont see any check for other kinds of shared pages in the >>>>> code. >>>> >>>> >>>> Agreed. "shared" here seems confused. I've removed it. And I've >>>> added mention of "Huge TLB pages" for this error. >>> >>> >>> Thanks. >> >> >> I also added those cases for MADV_REMOVE, BTW. > > > Right. There's also the following for MADV_REMOVE that needs updating: > > "Currently, only shmfs/tmpfs supports this; other filesystems return with > the error ENOSYS." > > - it's not just shmem/tmpfs anymore. It should be best to refer to > fallocate(2) option FALLOC_FL_PUNCH_HOLE which seems to be (more) up to > date. > > - AFAICS it doesn't return ENOSYS but EOPNOTSUPP. Also neither error code= is > listed in the ERRORS section. Yup, I recently added that as well, based on a patch from Jan Chaloupka. >>>>>>> - The word "will result" did sound as a guarantee at least to me. S= o >>>>>>> here it >>>>>>> could be changed to "may result (unless the advice is ignored)"? >>>>>> >>>>>> It's too late to fix documentation. Applications already depends on >>>>>> the >>>>>> beheviour. >>>>> >>>>> Right, so as long as they check for EINVAL, it should be safe. It >>>>> appears >>>>> that >>>>> jemalloc does. >>>> >>>> So, first a brief question: in the cases where the call does not error >>>> out, >>>> are we agreed that in the current implementation, MADV_DONTNEED will >>>> always result in zero-filled pages when the region is faulted back in >>>> (when we consider pages that are not backed by a file)? >>> >>> I'd agree at this point. >> >> Thanks for the confirmation. >> >>> Also we should probably mention anonymously shared pages (shmem). I thi= nk >>> they behave the same as file here. >> >> You mean tmpfs here, right? (I don't keep all of the synonyms straight.) > > shmem is tmpfs (that by itself would fit under "files" just fine), but al= so > sys V segments created by shmget(2) and also mappings created by mmap wit= h > MAP_SHARED | MAP_ANONYMOUS. I'm not sure if there's a single manpage to > refer to the full list. So, how about this text: After a successful MADV_DONTNEED operation, the seman=E2=80= =90 tics of memory access in the specified region are changed: subsequent accesses of pages in the range will succeed, but will result in either reloading of the memory contents from the underlying mapped file (for shared file mappings, shared anonymous mappings, and shmem-based techniques such as System V shared memory segments) or zero-fill-on-demand pages for anonymous private mappings. Thanks, Michael -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org