From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6C909C43331 for ; Fri, 3 Apr 2020 11:21:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D97C720737 for ; Fri, 3 Apr 2020 11:21:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=fb.com header.i=@fb.com header.b="cAAo3p62"; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.i=@fb.onmicrosoft.com header.b="hHRyMcu2" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D97C720737 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=fb.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 776D18E0008; Fri, 3 Apr 2020 07:21:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 726CB8E0007; Fri, 3 Apr 2020 07:21:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5EF9E8E0008; Fri, 3 Apr 2020 07:21:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0023.hostedemail.com [216.40.44.23]) by kanga.kvack.org (Postfix) with ESMTP id 425D48E0007 for ; Fri, 3 Apr 2020 07:21:12 -0400 (EDT) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id F3643824556B for ; Fri, 3 Apr 2020 11:21:11 +0000 (UTC) X-FDA: 76666302384.09.mint00_7ec1cbddbcc43 X-HE-Tag: mint00_7ec1cbddbcc43 X-Filterd-Recvd-Size: 23887 Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) by imf16.hostedemail.com (Postfix) with ESMTP for ; Fri, 3 Apr 2020 11:21:10 +0000 (UTC) Received: from pps.filterd (m0109331.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 033BJLXX025081; Fri, 3 Apr 2020 04:21:08 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=EXXj0K5e+J1wp8n0JmR9EexCqxYhjTcmUlfmsCJQcRs=; b=cAAo3p62mDRkC1WYvG//bexYa+ucU+sl6pGW3vaoiIHU43hvTBnFHz8qCTLqrUgLJ/dy hUofzae+Mf67SZ1fu0B//qGem9XLATfufiw7bfQk1tl5I54PBr0VI+rXeBxmq5IBvRxg 0xQnBEIAvXLk5TZitd2hAxjv/XRCXjRsKkQ= Received: from mail.thefacebook.com ([163.114.132.120]) by mx0a-00082601.pphosted.com with ESMTP id 304cxbxf8a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 03 Apr 2020 04:21:08 -0700 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (100.104.98.9) by o365-in.thefacebook.com (100.104.94.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Fri, 3 Apr 2020 04:21:07 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ee8GL118RRv5ZlOIruOetJ7PIaFZUBd85hmlQi39s+EK9SCVaYTdpfcGAkKoeTn7wmKf2UUlf/tHtNfjV4SRHBZRzayUElptn2qrvx58uxzXDacIvONl1TRItSPiD1+SowuXQzZDg1OmEiIrwbrtQS407PevF4MBC0836fPHyhFOzhnqC36Q78G0Wj7rEroQ7QXD8QReD+WY5Gw7BLqsovc53yczPFcifX1Jxs6BMT2nYkTN/fpz21x9sGGnprl93DSvfFA2YVutriBiila6o2p5TUGwhveUXLMZDw/VLn9C7FRWHzVizxNmOytilkM7CvrWAdSwOoaqcnLl12CY3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EXXj0K5e+J1wp8n0JmR9EexCqxYhjTcmUlfmsCJQcRs=; b=G5ftghKOzCs8EtPaoIufR89rTAip6JQltohefYgbz+RzVr+keUwgI+KAb3GXHBchlDii6D1nBx87udy8ePj7bC9As72XC8DwuPmOFKuhxGwPZFkT8TzQUuJ67E6PNh9zeGFNNBlGUClD3oOYa0dt+kEd1JmF9IeuM9XwyEr+Np/CL9EAP6v3fQh5rxkZ5zUBF/gsaV4OJFRy+/GCgshwglf3unaBsUmFx6bJdONCDkL8TV1I+g4+Wn/z38Y2cDGbJVTekJn6Nt0LnYW9Itcx3NEKPbJJ7K0hdiSFp9/PXIrxycIwVpPAqnN665b7faF2whkvsoGtz4pqIa+iAHOaMg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=fb.com; dmarc=pass action=none header.from=fb.com; dkim=pass header.d=fb.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector2-fb-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EXXj0K5e+J1wp8n0JmR9EexCqxYhjTcmUlfmsCJQcRs=; b=hHRyMcu22svw3x9v9dpeCxAe3cEJT2c9/HlwzE1Da9XOhS6mUtnKjjvvXQRGzr9R/dCZ8aC4BL2Os2YA3XcMtjj1GWnYz+oMVqtcwbyfO7wAbR/UzVrbyKOZ1RifB7vD3dGAc8SDRIaLMn2FfJP0/4QttzpZdhg0EHsUSmQez0E= Received: from MN2PR15MB3597.namprd15.prod.outlook.com (2603:10b6:208:1b6::21) by MN2PR15MB2558.namprd15.prod.outlook.com (2603:10b6:208:122::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20; Fri, 3 Apr 2020 11:21:05 +0000 Received: from MN2PR15MB3597.namprd15.prod.outlook.com ([fe80::38c0:f68d:40e:238c]) by MN2PR15MB3597.namprd15.prod.outlook.com ([fe80::38c0:f68d:40e:238c%7]) with mapi id 15.20.2878.017; Fri, 3 Apr 2020 11:21:05 +0000 From: Aslan Bakirov To: Michal Hocko CC: "akpm@linux-foundation.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , Kernel Team , "riel@surriel.com" , Roman Gushchin , "hannes@cmpxchg.org" Subject: Re: [PATCH 2/2] mm: hugetlb: Use node interface of cma Thread-Topic: [PATCH 2/2] mm: hugetlb: Use node interface of cma Thread-Index: AQHWCaFfY5dTdZWB0UeKWwtXDiKFHqhnNE+AgAAMIQ8= Date: Fri, 3 Apr 2020 11:21:05 +0000 Message-ID: References: <20200403101843.406634-1-aslan@fb.com> <20200403101843.406634-2-aslan@fb.com>,<20200403103651.GA22681@dhcp22.suse.cz> In-Reply-To: <20200403103651.GA22681@dhcp22.suse.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c093:400::5:eef3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 73971397-c2e7-4ba0-f213-08d7d7c11983 x-ms-traffictypediagnostic: MN2PR15MB2558: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-fb-source: Internal x-ms-oob-tlc-oobclassifiers: OLM:3044; x-forefront-prvs: 0362BF9FDB x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN2PR15MB3597.namprd15.prod.outlook.com;PTR:;CAT:NONE;SFTY:;SFS:(10019020)(376002)(346002)(366004)(396003)(39860400002)(136003)(76116006)(54906003)(8936002)(6916009)(81166006)(55016002)(8676002)(53546011)(478600001)(64756008)(52536014)(66476007)(40265005)(5660300002)(6506007)(7696005)(66446008)(9686003)(86362001)(66556008)(19627405001)(91956017)(66946007)(71200400001)(186003)(81156014)(966005)(316002)(4326008)(2906002)(33656002);DIR:OUT;SFP:1102; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: EN/vhDe3HjuOB+h7Ai5qN2W/HexoOSF83EVQMJqlApIKFCxcUrkpwLMZdq4xc+ps+QtmSdhd2VncnJ4jV8sZwJKlZer6k1bioB7SxKQ4yy8hwujBnhjKoGg0vgCfYKZDFIdcAkzuTuX+dWGLS1WTyrTWtOf5XgOzGTjnMeW0lWxDe9KS2y2sxfcR6jEHlqIn+etV+TPZcweRD1cVzqNnQt+XyJrCVgJvNGnMAVJNalbNBgszSJkWt9xSfTfxEpvHQ69FZodH8IWZKcZ0RKMPHdgU+KC5EJSjTKAcX7Y5BOPEzYvRkm7Wsv/NdWX/LymOD9uitBMhMUcjaAOzLPvH1bDIgNGV3rvB9BEz9DxZUt1OniX1oqw32rg9ZiOHRPXzE+IXPdmetaIimHhiQVgtIpwph+7t6tUHza/d6H+rHqSVN0MROvwdHbGgHJ9djsuiv2cziUTpKdN0qaXZQkv0RGMWrXmj53nFsRBXgA/AONdNaCbYltmauBnfLWPR4XQbJe89V4ZJh170HlQidvEYRw== x-ms-exchange-antispam-messagedata: 4U+BK4VF0ETFV0FTNgkXKRi4Y/00E33QczlBbM5D8qXnjOhjrGXd73q4fx6++owvZsZfl3ZCbwe1fEG7bWAc8RU6eUW/gRUBKEVOo7GpsT9eFC98zqMhLxRSdMMCj+l/l8ZrXorlsZVq7Y6/aNS9ny9DJ7Q28Nb+g03IZQdeIVIVEiwOzTE4KXE/qPWzTyo2 Content-Type: multipart/alternative; boundary="_000_MN2PR15MB35972EB0533A0548C264757CC0C70MN2PR15MB3597namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 73971397-c2e7-4ba0-f213-08d7d7c11983 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2020 11:21:05.1233 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 6lwQpcOakP1zxdBQZwGlQsIwS9eklBCcuwHMXXCzAz/ovMoW7xjyRo2Hmizv+BKi X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR15MB2558 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138,18.0.676 definitions=2020-04-03_07:2020-04-02,2020-04-03 signatures=0 X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 malwarescore=0 phishscore=0 suspectscore=0 mlxlogscore=999 mlxscore=0 clxscore=1015 spamscore=0 impostorscore=0 priorityscore=1501 lowpriorityscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004030099 X-FB-Internal: deliver X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: --_000_MN2PR15MB35972EB0533A0548C264757CC0C70MN2PR15MB3597namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ________________________________ From: Michal Hocko Sent: Friday, April 3, 2020 11:36 AM To: Aslan Bakirov Cc: akpm@linux-foundation.org ; linux-kernel@vge= r.kernel.org ; linux-mm@kvack.org ; Kernel Team ; riel@surriel.com ; Roman Gushchin ; hannes@cmpxchg.org Subject: Re: [PATCH 2/2] mm: hugetlb: Use node interface of cma On Fri 03-04-20 03:18:43, Aslan Bakirov wrote: > With introduction of numa node interface for CMA, this patch is for using= that > interface for allocating memory on numa nodes if NUMA is configured. > This will be more efficient and cleaner because first, instead of iterat= ing > mem range of each numa node, cma_declare_contigueous_nid() will do > its own address finding if we pass 0 for both min_pfn and max_pfn, > second, it can also handle caseswhere NUMA is not configured > by passing NUMA_NO_NODE as an argument. > > In addition, checking if desired size of memory is available or not, > is happening in cma_declare_contiguous_nid() because base and > limit will be determined there, since 0(any) for base and > 0(any) for limit is passed as argument to the function. I have asked to merge this one with the original patch from Roman several times but it seems this is not going to happen. But whatever. You have likely missed my review feedback http://lkml.kernel.org/r/20200402= 172404.GV22681@dhcp22.suse.cz. The ifdef CONFIG_NUMA for the nid definition is pointless. > Signed-off-by: Aslan Bakirov After fixing that, feel free to add Acked-by: Michal Hocko Addressed your comment, and updated the patch. Thanks Michal. > --- > mm/hugetlb.c | 40 +++++++++++----------------------------- > 1 file changed, 11 insertions(+), 29 deletions(-) > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > index b9f0c903c4cf..62989220c4ff 100644 > --- a/mm/hugetlb.c > +++ b/mm/hugetlb.c > @@ -5573,42 +5573,24 @@ void __init hugetlb_cma_reserve(int order) > > reserved =3D 0; > for_each_node_state(nid, N_ONLINE) { > - unsigned long min_pfn =3D 0, max_pfn =3D 0; > int res; > -#ifdef CONFIG_NUMA > - unsigned long start_pfn, end_pfn; > - int i; > > - for_each_mem_pfn_range(i, nid, &start_pfn, &end_pfn, NULL) = { > - if (!min_pfn) > - min_pfn =3D start_pfn; > - max_pfn =3D end_pfn; > - } > -#else > - min_pfn =3D min_low_pfn; > - max_pfn =3D max_low_pfn; > -#endif > size =3D min(per_node, hugetlb_cma_size - reserved); > size =3D round_up(size, PAGE_SIZE << order); > - > - if (size > ((max_pfn - min_pfn) << PAGE_SHIFT) / 2) { > - pr_warn("hugetlb_cma: cma_area is too big, please t= ry less than %lu MiB\n", > - round_down(((max_pfn - min_pfn) << PAGE_SHI= FT) * > - nr_online_nodes / 2 / SZ_1M, > - PAGE_SIZE << order)); > - break; > - } > - > - res =3D cma_declare_contiguous(PFN_PHYS(min_pfn), size, > - PFN_PHYS(max_pfn), > + > + > +#ifndef CONFIG_NUMA > + nid =3D NUMA_NO_NODE > +#endif > + res =3D cma_declare_contiguous_nid(0, size, > + 0, > PAGE_SIZE << order, > 0, false, > - "hugetlb", &hugetlb_cma[nid]); > + "hugetlb", &hugetlb_cma[nid], = nid); > + > if (res) { > - phys_addr_t begpa =3D PFN_PHYS(min_pfn); > - phys_addr_t endpa =3D PFN_PHYS(max_pfn); > - pr_warn("%s: reservation failed: err %d, node %d, [= %pap, %pap)\n", > - __func__, res, nid, &begpa, &endpa); > + pr_warn("%s: reservation failed: err %d, node %d\n"= , > + __func__, res, nid); > break; > } > > -- > 2.24.1 -- Michal Hocko SUSE Labs --_000_MN2PR15MB35972EB0533A0548C264757CC0C70MN2PR15MB3597namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


From: Michal Hocko <mhoc= ko@kernel.org>
Sent: Friday, April 3, 2020 11:36 AM
To: Aslan Bakirov <aslan@fb.com>
Cc: akpm@linux-foundation.org <akpm@linux-foundation.org>; lin= ux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>; linux-mm@kv= ack.org <linux-mm@kvack.org>; Kernel Team <Kernel-team@fb.com>;= riel@surriel.com <riel@surriel.com>; Roman Gushchin <guro@fb.com&= gt;; hannes@cmpxchg.org <hannes@cmpxchg.org>
Subject: Re: [PATCH 2/2] mm: hugetlb: Use node interface of cma
 
On Fri 03-04-20 03:18:43, Aslan Bakirov wrote:
> With introduction of numa node interface for CMA, this patch is for us= ing that
> interface for allocating memory on numa nodes if NUMA is configured. > This will be more efficient  and cleaner because first, instead o= f iterating
> mem range of each numa node, cma_declare_contigueous_nid() will do
> its own address finding if we pass 0 for  both min_pfn and max_pf= n,
> second, it can also handle caseswhere NUMA is not configured
> by passing NUMA_NO_NODE as an argument.
>
> In addition, checking if desired size of memory is available or not, > is happening in cma_declare_contiguous_nid()  because base and > limit will be determined there, since 0(any) for  base and
> 0(any) for limit is passed as argument to the function.

I have asked to merge this one with the original patch from Roman
several times but it seems this is not going to happen. But whatever.

You have likely missed my review feedback http://lkml.kernel.org/r/20200402172404.GV22681@dhcp22.suse.cz.
The ifdef CONFIG_NUMA for the nid definition is pointless.

> Signed-off-by: Aslan Bakirov <aslan@fb.com>

After fixing that, feel free to add
Acked-by: Michal Hocko <mhocko@suse.com>

Addressed  your comment, and updated the patc= h. Thanks Michal.

> ---
>  mm/hugetlb.c | 40 +++++++++&= #43;+-----------------------------
>  1 file changed, 11 insertions(+), 29 deletions(-)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index b9f0c903c4cf..62989220c4ff 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -5573,42 +5573,24 @@ void __init hugetlb_cma_reserve(int order)=
> 
>        reserved =3D 0;
>        for_each_node_state(nid, N_O= NLINE) {
> -           &nb= sp; unsigned long min_pfn =3D 0, max_pfn =3D 0;
>            = ;    int res;
> -#ifdef CONFIG_NUMA
> -           &nb= sp; unsigned long start_pfn, end_pfn;
> -           &nb= sp; int i;
> 
> -           &nb= sp; for_each_mem_pfn_range(i, nid, &start_pfn, &end_pfn, NULL) { > -           &nb= sp;         if (!min_pfn)
> -           &nb= sp;            =      min_pfn =3D start_pfn;
> -           &nb= sp;         max_pfn =3D end_pfn; > -           &nb= sp; }
> -#else
> -           &nb= sp; min_pfn =3D min_low_pfn;
> -           &nb= sp; max_pfn =3D max_low_pfn;
> -#endif
>            = ;    size =3D min(per_node, hugetlb_cma_size - reserved); >            = ;    size =3D round_up(size, PAGE_SIZE << order);
> -
> -           &nb= sp; if (size > ((max_pfn - min_pfn) << PAGE_SHIFT) / 2) {
> -           &nb= sp;         pr_warn("hugetlb_c= ma: cma_area is too big, please try less than %lu MiB\n",
> -           &nb= sp;            =      round_down(((max_pfn - min_pfn) << PAGE_SHIF= T) *
> -           &nb= sp;            =             &nb= sp;   nr_online_nodes / 2 / SZ_1M,
> -           &nb= sp;            =             &nb= sp;   PAGE_SIZE << order));
> -           &nb= sp;         break;
> -           &nb= sp; }
> -
> -           &nb= sp; res =3D cma_declare_contiguous(PFN_PHYS(min_pfn), size,
> -           &nb= sp;            =             &nb= sp;     PFN_PHYS(max_pfn),
> +           = ; 
> +           = ; 
> +#ifndef CONFIG_NUMA
> +           = ;  nid =3D NUMA_NO_NODE
> +#endif          = ;    

> +           = ;  res =3D cma_declare_contiguous_nid(0, size,
> +           = ;            &n= bsp;            = ;      0,
>            = ;            &n= bsp;            = ;        PAGE_SIZE << order,
>            = ;            &n= bsp;            = ;        0, false,
> -           &nb= sp;            =             &nb= sp;     "hugetlb", &hugetlb_cma[nid]); > +           = ;            &n= bsp;            = ;      "hugetlb", &hugetlb_cma[nid],= nid);        
> +
>            = ;    if (res) {
> -           &nb= sp;         phys_addr_t begpa =3D P= FN_PHYS(min_pfn);
> -           &nb= sp;         phys_addr_t endpa =3D P= FN_PHYS(max_pfn);
> -           &nb= sp;         pr_warn("%s: reser= vation failed: err %d, node %d, [%pap, %pap)\n",
> -           &nb= sp;            =      __func__, res, nid, &begpa, &endpa);
> +           = ;          pr_warn("%s: r= eservation failed: err %d, node %d\n",
> +           = ;            &n= bsp;     __func__, res, nid);
>            = ;            break;<= br> >            = ;    }
> 
> --
> 2.24.1

--
Michal Hocko
SUSE Labs
--_000_MN2PR15MB35972EB0533A0548C264757CC0C70MN2PR15MB3597namp_--