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=-5.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MSGID_FROM_MTA_HEADER,SPF_HELO_NONE,SPF_PASS 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 39381C433ED for ; Wed, 31 Mar 2021 14:48:49 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B9EB96101A for ; Wed, 31 Mar 2021 14:48:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B9EB96101A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=nvidia.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 162FE6B0085; Wed, 31 Mar 2021 10:48:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0EC0C6B0087; Wed, 31 Mar 2021 10:48:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E59866B0088; Wed, 31 Mar 2021 10:48:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0209.hostedemail.com [216.40.44.209]) by kanga.kvack.org (Postfix) with ESMTP id C6C2A6B0085 for ; Wed, 31 Mar 2021 10:48:47 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 7FF04180AC462 for ; Wed, 31 Mar 2021 14:48:47 +0000 (UTC) X-FDA: 77980451094.14.A71840E Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2077.outbound.protection.outlook.com [40.107.92.77]) by imf11.hostedemail.com (Postfix) with ESMTP id E44992000244 for ; Wed, 31 Mar 2021 14:48:45 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QHJzlLoufx7iNg28y/nCK8PDgetc2V9IXRFnvyNiJVZn6ExC1++EQXiQpC2xOUt/I2XlYUYFBkClUOA9sWhZzmq3z4PPqPvlWlwvkNDzIqxg+P6uqZrQhFyp04EXi4ww5U0UsLMfQ68zh9p2YQX6zDEad2v1L3cOV8+Uesm2KhFZw+imzA3fj7GkINEppANsvJg40CRV1rahutymJlnn5YUi5j9mVLuzTm6sxoQupYWRpYWcLkX3RtiQu6s/gzhj/3bPDNBuakD6ZT1Exqmg/0zQvRpOpMdc6N4Rx92kGvBZ9kPnZViOxs5UXCMWPPw9mc4fU9f3NHCSi0zolJU08g== 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=Zrmk8imEjE4VVCTOUpRYPefPooc11A9iDANXe4H5zd8=; b=T2GqfDEX2DVe9/yrGokYspnPdUroZ5fH5TuIileXra54/pRfGrmqkZNC4SLPnCm2ouQLsSB5Gzo208rQPS08IjKBYXrZLC5ELeThY+DCfRZAWQjSsDe4Rh2YKZ0Uf60Z1b6n8vwLrb5OSI3p9Cl8pkyUjnwCppmXPmym80H6upuZRk76KxFUV6PkTteQiV2jZuAC3ytCllW6dXyD3uJMPLxgUs/sLhZfON1Y5ywyqGDnBznuWkVD9EhmEhmDqbfXCSE8VPkmmkMGb2Bss00CeRqmqa//iYfpWRRK58uMALbjt6CqfXBMzuG1DL3hk/eP9a420DIwgKl5fQKDuqYyEA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Zrmk8imEjE4VVCTOUpRYPefPooc11A9iDANXe4H5zd8=; b=Q2UQb5QM2Ws5AWejRn000FhcsSGo2v5xG7i5z8wYRpU1niz0AQavkFafESZiud0wRSRC6JUyFeqbBfADem81bz9YXcldD7g/UPOfoph+0F4CLq7CS5AO6OUD2OCan2qaaoK/6RUiMPaxeeuHDxdyLYvjv7/9CmozB1KwYOYsArp2jPNPt5jqJoHLvQDzgqNzpjrK9l4m2vh/HjjoBWLSODTKLuWsxDc1AB7J03YoL7LGmTYqj/me6E71Hr3OF9cPS75r03ehzMkhdvyFFpBdzL4IDObgNCfBxbwS7iuFH3C+aivctvremnestRP2wjs7K5iASLpaXFlgsQkcNt07BA== Authentication-Results: fb.com; dkim=none (message not signed) header.d=none;fb.com; dmarc=none action=none header.from=nvidia.com; Received: from MN2PR12MB3823.namprd12.prod.outlook.com (2603:10b6:208:168::26) by BL0PR12MB2465.namprd12.prod.outlook.com (2603:10b6:207:45::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.26; Wed, 31 Mar 2021 14:48:44 +0000 Received: from MN2PR12MB3823.namprd12.prod.outlook.com ([fe80::a1b1:5d8:47d7:4b60]) by MN2PR12MB3823.namprd12.prod.outlook.com ([fe80::a1b1:5d8:47d7:4b60%7]) with mapi id 15.20.3999.027; Wed, 31 Mar 2021 14:48:44 +0000 From: "Zi Yan" To: "Roman Gushchin" , "Matthew Wilcox" Cc: linux-mm@kvack.org, "Kirill A . Shutemov" , "Andrew Morton" , "Yang Shi" , "Michal Hocko" , "John Hubbard" , "Ralph Campbell" , "David Nellans" , "Jason Gunthorpe" , "David Rientjes" , "Vlastimil Babka" , "David Hildenbrand" , "Mike Kravetz" , "Song Liu" Subject: Re: [RFC PATCH v3 00/49] 1GB PUD THP support on x86_64 Date: Wed, 31 Mar 2021 10:48:36 -0400 X-Mailer: MailMate (1.14r5757) Message-ID: <85EDDC81-72F8-4204-A111-73AEAEADA2AF@nvidia.com> In-Reply-To: References: <20210224223536.803765-1-zi.yan@sent.com> <890DE8FE-DAF6-49A2-8C62-40B6FD593B4A@nvidia.com> <06D1034A-DE8B-4970-9056-6CA1C436D2E8@nvidia.com> <20210331030935.GT351017@casper.infradead.org> Content-Type: multipart/signed; boundary="=_MailMate_2B65157D-85B4-47DD-8BE5-8F9C03FD0A8A_="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Originating-IP: [216.228.112.21] X-ClientProxiedBy: MN2PR20CA0038.namprd20.prod.outlook.com (2603:10b6:208:235::7) To MN2PR12MB3823.namprd12.prod.outlook.com (2603:10b6:208:168::26) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.2.57.140] (216.228.112.21) by MN2PR20CA0038.namprd20.prod.outlook.com (2603:10b6:208:235::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.26 via Frontend Transport; Wed, 31 Mar 2021 14:48:40 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 52945bc1-37a9-44e1-a822-08d8f45414b4 X-MS-TrafficTypeDiagnostic: BL0PR12MB2465: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: SDUWgcWRnQd7c+KFqJllT+dh9NdFFQyTBLctUPIi7itcuMM1M1Y24rwOhQQl2xDHh2gMlpVF+5Xhq5duMZHbyOVo5UYiB+XFKMbQmVtuABAGcFie8uyqIFs2O74xa2BPJQrMQFvd/IKPfpWWHyqDXUkZfbC7BVZ6sC76A3mHiT4jXFNpW49iSuEtd3ocSjyK+/A9Nul6/LAiS4IBdiprE+DIM0fKFTcX9zNZfMrqkeWxG5O0B74VnTrXihwGWljo8vt66ypXxGApJcxXtQU+NwxnU9KITqrlaQEFlEV5fEISgsoOow/hGPxFK0KEDGubRdjhSEpaOlKyNospaRjQtkdHtcDEqjm1A5N1vehNUT0xhA8tBYvZwAphtTdZwTGzLK2/8TVjDbzf2SkZ5JHDjJxmjdQd24lr2ZPBYL/uSOrNjd/LpQf90mKy3Ll8X2suX16EGIsCy/nNEXSDYixyC69f4duk73pMojZofty89CO4a2kf5KwnBKdD2wmBSR6/skaw5tfwGJ55gGQzJeSiwIinoO8RqOLt0/fTUMq/aEmFiREqJuXFf4ua6B7kHAzW0Y11RJMwkXSkTd65VGofjApa0KWZ74gaa3C0SqsDIQI+Nk6Pfk3izxjDCvlEqAo4lBCWS2XAx6u4OUh8DBwyQUoQolAsqLSs8fjIqPnLI6fzgmw83TPhZPLUVUwHkTXMjzo6jAXqm5GT7hlRKrfY9KhhKh7MP5tewZU6xoi7w5aDtkDS2ydTBBv9yQzPd7xjB5DU/5L+JBfwqrCz0ROzGQHVnxQiua2H7yXwzdjJupA= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN2PR12MB3823.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(4636009)(376002)(346002)(366004)(39860400002)(136003)(396003)(956004)(110136005)(36756003)(54906003)(16576012)(478600001)(316002)(38100700001)(8936002)(966005)(2616005)(26005)(53546011)(5660300002)(4326008)(16526019)(33656002)(186003)(2906002)(6486002)(8676002)(66946007)(66556008)(66476007)(235185007)(7416002)(6666004)(33964004)(83380400001)(86362001)(45980500001)(72826003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?SzhNMEwzL3p1WTlJMUZTQXVTMTVRSUF0cTIrcjc2Tjl4Qmk2UVdrZHdIUVlQ?= =?utf-8?B?ZTBBYzNZdyswMlJXeVlyUWxYZytwcFFYWkJRZXRLMkxXZERoVVE3WElBbXk5?= =?utf-8?B?RDMvOVIrUUUxODNPbG5YbFdKNEVCY0ZsdUZBM3RQenZBeUNQbmU0cHdzVm9G?= =?utf-8?B?elF0S3VPVXY4SVpCeEd0U3Q2dVZab21pK0F1N3FRWDFheVNnUDVpaXk2RTlm?= =?utf-8?B?TE1rNXoxVCt2RVluMThuRTNlMWp1QVF4cmhMRFo2V1dPMldNQ0tpc3ExaHVO?= =?utf-8?B?d2hHY2FvdFpoTVJ4WHgxRWs4ZlVyb002V21FZW1HK3F5dE93THg0ZkFLRDdi?= =?utf-8?B?d2oyOGdaLytGOXQwTmFkRWhEVWZoYkI1R3RZY1BzZ2xQeWVHOGFsVDlEWms5?= =?utf-8?B?bmNuZit0UXNVL29GZ01PdWl2M3lXUUo2cGtpTVAvSjJsWG1PUC94N2RML3A1?= =?utf-8?B?UmxFUkg2T3VVbmtQVUJTSFliVFVpV0d0aFpLTWJ5cCt2Qmcyb05SNXFhaFh1?= =?utf-8?B?S0o5Q1AyT2JqbjJBZGxERDhrY3Z4UlR0ODdBd2ljWmhUTUhaZlpUV0hjMHFO?= =?utf-8?B?OWY5Z0JpQmRmcUpncUdDYnVrRkh4dkxNL01aRk85UloyWXp5YVRCYkFSU3lW?= =?utf-8?B?MVBBVFRQTmliekx4bHAycEFmUlBXYU5qeitRWGJoRkZkNDJVMHRsSzczcU90?= =?utf-8?B?Q2FjK2NYcTVHNFV2RUxDVW1mdHlrTlIvYXFabW14ZzkxTDQxSmNadnJ5VmE4?= =?utf-8?B?SGg3MlZybFZZZEFUWCsxSVZnWU5VZnRtVE9GRUc2bStVb09FTTUrdnFXZUh2?= =?utf-8?B?Rno3RHNBN2M0OWVHbUkySU9UU3ZZRU5LK1dtTDBGVHVPMmRxYVZOODJ1ZkdE?= =?utf-8?B?V2M1S0dETzR2OUZhZFh3emJJaC8yOWhuaFZjcnJad0Uwak5aVVVRN01EdlM3?= =?utf-8?B?OXZnM2FNY2VVek01TXZ1VGU2eDAzQXV1ejJJSHNXSGxTY1puYXAydFJJQjh1?= =?utf-8?B?QUl4T1Q0b05tSSt3QUF3YmlYRUM5dVNSNUR3dWxCUmU2Mm9ZQ2J0dVpJU0Nz?= =?utf-8?B?TTh6WDU1VWlxN2ZEdWwwdXMvWi9RMTB5QXVlZW9iSTJWdUVtazJLb3J6T05x?= =?utf-8?B?Z2QxUlBkVk82YWMzc0VPM1RlTm5TWTBSem54TXNVTXpsaXZUa3l5ZzlMQW1q?= =?utf-8?B?ZVBtYStpcERudDhSSFIwalAzOU9uNVJOYmdaL0VCOWs2OHYrU01mTUJqY21T?= =?utf-8?B?Z1JRaEwrOTlsNDFtNlNLQVZqem1qZm5KeEU2M3R2UVZmUnhMRkJXNTVJT2Ex?= =?utf-8?B?NWU5MEd3c1ZzaWtUUmh0QmIzeWtpTjN3N25BQlN2QkhYU3ZvMmNUaGw4TE51?= =?utf-8?B?ck03VkhOMDhxTk0vYWFER2JKSVZwRWZFUjhmVmo4clIzNlQvVW5tZE9EYXND?= =?utf-8?B?ck52SVpxd0RUNFk3NndFNW12MGR1Mjc5ZDVBcEZKcVZWRlBOdk01VzQyUXN3?= =?utf-8?B?NmYvYmV6akJNOElWTGJRMGNNWEFua0tybWxqOVlUUmxwZGFLQmZqMm8wZlNI?= =?utf-8?B?MjV6Nnc3dmwyZG1oZlhSRW1ONDR4YlNuUTRuUnMwbzh2eUZ1RG5ITkpOZ2kr?= =?utf-8?B?cE1rRDBlYlMvTHZLajlyTFBRVVZJSVpyYy9VZDRDWHlGQUtmMG5ySytnbzlZ?= =?utf-8?B?TkpmamhncnpYaDNLYWtrNzNmSTFOWDdKVDFQTXdFS2U4bGtjYy9MSFlQYkh0?= =?utf-8?Q?HvFbB628u++ttwX47Wd0M+LgE7CX4RwFkZEMzJu?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 52945bc1-37a9-44e1-a822-08d8f45414b4 X-MS-Exchange-CrossTenant-AuthSource: MN2PR12MB3823.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Mar 2021 14:48:43.7797 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: A4K/vfJI0zfQPaLL4X7NpCt5hUrqOPsZO2ud4njhY/bYasseabc9wzR5gfmWdzFb X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR12MB2465 X-Stat-Signature: xoip979xodtmbc6w91mt4fbyaj3s887p X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: E44992000244 Received-SPF: none (nvidia.com>: No applicable sender policy available) receiver=imf11; identity=mailfrom; envelope-from=""; helo=NAM10-BN7-obe.outbound.protection.outlook.com; client-ip=40.107.92.77 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1617202125-61689 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: --=_MailMate_2B65157D-85B4-47DD-8BE5-8F9C03FD0A8A_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 30 Mar 2021, at 23:32, Roman Gushchin wrote: > On Wed, Mar 31, 2021 at 04:09:35AM +0100, Matthew Wilcox wrote: >> On Tue, Mar 30, 2021 at 11:02:07AM -0700, Roman Gushchin wrote: >>> On Tue, Mar 30, 2021 at 01:24:14PM -0400, Zi Yan wrote: >>>> On 4 Mar 2021, at 11:45, Roman Gushchin wrote: >>>>> I actually ran a large scale experiment (on tens of thousands of ma= chines) in the last >>>>> several months. It was about hugetlbfs 1GB pages, but the allocatio= n mechanism is the same. >>>> >>>> Thanks for the information. I finally have time to come back to this= =2E Do you mind sharing >>>> the total memory of these machines? I want to have some idea on the = scale of this issue to >>>> make sure I reproduce in a proper machine. Are you trying to get <20= % of 10s GBs, 100s GBs, >>>> or TBs memory? >>> >>> There are different configurations, but in general they are in 100's = GB or smaller. >> >> Are you using ZONE_MOVEABLE? Seeing /proc/buddyinfo from one of these= >> machines might be illuminating. > > No, I'm using pre-allocated cma areas, and it works fine. > Buddyinfo stops at order 10, right? > How it's helpful with fragmentation on 1GB scale? > >> >>>> >>>>> >>>>> My goal as to allocate a relatively small number of 1GB pages (<20%= of the total memory). >>>>> Without cma chances are reaching 0% very fast after reboot, and eve= n manual manipulations >>>>> like shutting down all workloads, dropping caches, calling sync, co= mpaction, etc. do not >>>>> help much. Sometimes you can allocate maybe 1-2 pages, but that's a= bout it. >>>> >>>> Is there a way of replicating such an environment with publicly avai= lable software? >>>> I really want to understand the root cause and am willing to find a = possible solution. >>>> It would be much easier if I can reproduce this locally. >>> >>> There is nothing fb-specific: once the memory is filled with anon/pag= ecache, any subsequent >>> allocations of non-movable memory (slabs, percpu, etc) will fragment = the memory. There >>> is a pageblock mechanism which prevents the fragmentation on 2MB scal= e, but nothing prevents >>> the fragmentation on 1GB scale. It just a matter of runtime (and the = number of mm operations). >> >> I think this is somewhere the buddy allocator could be improved. >> Of course, it knows nothing of larger page orders (which needs to be >> fixed), but in general, I would like it to do a better job of segregat= ing >> movable and unmovable allocations. >> >> Let's take a machine with 100GB of memory as an example. Ideally, >> unmovable allocations would start at 4GB (assuming below 4GB is >> ZONE_DMA32). Movable allocations can allocate anywhere in memory, but= >> should avoid being "near" unmovable allocations. Perhaps they start >> at 5GB. When unmovable allocations get up to 5GB, we should first exe= rt >> a bit of pressure to shrink the unmovable allocations (looking at you,= >> dcache), but eventually we'll need to grow the unmovable allocations >> above 5GB and we should move, say, all the pages between 5GB and 5GB+1= MB. >> If this unmovable allocation was just temporary, we get a reassembled >> 1MB page. If it was permanent, we now have 1MB of memory to soak up >> the next few allocations. >> >> The model I'm thinking of here is that we have a "line" in memory that= >> divides movable and unmovable allocations. It can move up, but there >> has to be significant memory pressure to do so. Hi Roman and Matthew, David Hildenbrand proposed an idea similar to Matthew=E2=80=99s, ZONE_PRE= FER_MOVABLE, which prefers movable allocation and is the fallback for unmovable alloca= tions when ZONE_NORMAL is full [1]. Also ZONE_PREFER_MOVABLE size can be change= d dynamically on demand. My concerns for the ideas like this are: 1. Some long-live unmovable pages might hold the boundary between movable= and unmovable, so the part for unmovable allocation might end up only increas= ing. Would something like, creating a lot of dentries by going through the fil= e system and keeping the last visited file open, make this happen? 2. The cost of pushing the boundary. Unless both movable and unmovable al= locations are going towards the boundary, kernel will need to migrate movable pages= to move the boundary. It would create noticeable latency for unmovable allocation= s that need to move the boundary, right? > > I agree. My idea (which I need to find some time to try) was to hack th= e pageblock > code so that if we convert a block to non-movable, we can convert an en= tire GB > around. In this case, all unmovable memory will likely fit into few 1GB= chunks, > leaving all other chunks movable. But from the security's point of view= it will > be less desirable, I guess. What do you think about it? I like this idea and have thought about it too. It could reuse existing f= ragmentation avoidance mechanism and does not have my concerns above. But there will s= till be some work to prevent more than one 1GB pageblock from being converted = after we add support for 1GB pageblock size, otherwise, memory can still be fra= gmented by unmovable pages when multiple 1GB pageblocks are converted to unmovabl= e ones, assuming movable allocation can fall back to unmovable pageblocks. [1] https://lore.kernel.org/linux-mm/6135d2c5-2a74-6ca8-4b3b-8ceb25c0d4b1= @redhat.com/ =E2=80=94 Best Regards, Yan Zi --=_MailMate_2B65157D-85B4-47DD-8BE5-8F9C03FD0A8A_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQJDBAEBCgAtFiEEh7yFAW3gwjwQ4C9anbJR82th+ooFAmBki8QPHHppeUBudmlk aWEuY29tAAoJEJ2yUfNrYfqKsFAQAKXDf1lZrlyhtn//2hozT4skZAC3ENk1JLyA ilROBItvBXq34/teZ4FaSh/hjfpzFzVYlWBmXOzZrTDT+QDT2jP0O6H8iqqlSBpX NuA4fmMDXygZtpP3gjMloLVvXQyNA+JOh/xc8PXsNs4Z3AqKdFGWSR0XxVaCALBH qEdiAoKjqM4f18PoL5zgykvZ6MgbzuRfR70TP71qJtGe7dH/14zrvrPJCBBPRD2q V2K46MwXjESoEQjdg+b8wXmS8NcGS3+eBIAL3oFwNbuGC5oE6fIZC2lr9UYPUfzJ oAT+a8qpiTr2TpqQKOdjrn6e41T2mxr0K7c9rMAsSDX+WfiYkvRoJcgShNWLxbga +15bPJf3btT100qBk5pukqaHB9Lo5ydS68D6eMnyvw5luSHhy9sh4tAiGAR/8Je5 eSFWKyDq/5qbKPXINd9WbbDJEA1hsyGveYIe7RFClBahvf2jpCk41Pfetpg86gng L0516Dcm8beJ7kj8Wa3G37U3Pe4jOC6hWeNeZRB018b5DGVQ6n5Rzatr+IO91hZF QXMJa/rRt7hvlKBwAUlLPkR2IRIghU9BzxwSEdt5lLEpctkMPRNEmJ0EImVAuux7 qL9vv85DBOqmLc8g4C22TOG9C1wmQ1xKImgC5k8TdfiZSlD/Ofkf4BSBuO0hwHPO N5GNzYus =+CV4 -----END PGP SIGNATURE----- --=_MailMate_2B65157D-85B4-47DD-8BE5-8F9C03FD0A8A_=--