From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f170.google.com (mail-qk0-f170.google.com [209.85.220.170]) by dpdk.org (Postfix) with ESMTP id A1AF6324E; Wed, 21 Jun 2017 09:22:46 +0200 (CEST) Received: by mail-qk0-f170.google.com with SMTP id r62so75872888qkf.0; Wed, 21 Jun 2017 00:22:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uKRrOOINFzaUAjT0hTnAQla8iHTxQ3Gnl/dhqLDR3Cc=; b=EuqXyaAm47DKCGTbMkBvM1g362OgqitKW+LXf/pBKrpgSvvTfVZ+sS2uEpAfurC5IW VbZCluptT7x0CsXGCNVeWbFoVSBsC7g2JURnyG+Eex+7d6PDn6vCj3cSxVhgGwDgozrS aZ+Dty2wXLHndJdN9F81N0tqLhC1BdOjQAQdTVV+Y6ydMoGh+pkJ0oNUMNKNlxgTk6K1 bVxcP3KuZhI/9SQkOQrMpfLf+hzB3K90PAPzStpOPSjBxlMbfqbiBF+8sjUxZjSoR2U4 GJbE9MlTPseF09CHQyGMOY+RGwh8uvZ5KPkEMF99a9tww4tGquL0kTJrKfwH1zTbanZ0 gNuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uKRrOOINFzaUAjT0hTnAQla8iHTxQ3Gnl/dhqLDR3Cc=; b=RNxLmfM7lnbG983qBShxA0rSB4LlfLrscJBWsiVfTzFkZVuDg4fdTZQma2JBWL3jc+ d6JI4nNX9guOVIla7kE5Z4zywdJ+ICvxqj5l2t2LeUpIxHxa8PBCOEk/FuO4sS5pw1nU HBv9h8jSddaZYQpci4GAJx0GIbUPWQqvXU+klDseXKKFqrXSs6LKNDHVTdLht91aU2zU hIpSUdhsPIFQ3LfF7Ci8ibiipZ10K+X1SKgoN3BWa2bPrI8P0yuQ0c7t92pBIsEYb2R7 jYzdKkbEonIzPOjY1mef1wVgiZoibC8myaAAwbLriPJLZ8eBjpoGjUa31GEdXeb/SCIX c2Bw== X-Gm-Message-State: AKS2vOyJpYlqVLWgvK8zKmVPO8N+D4hRRWWydx9TsBpAZqsA8BLvMRw1 gT1SAJfGG7sxrQc6K3dJ+B7wRS6a2w== X-Received: by 10.55.68.20 with SMTP id r20mr11361749qka.31.1498029766000; Wed, 21 Jun 2017 00:22:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.90.72 with HTTP; Wed, 21 Jun 2017 00:22:45 -0700 (PDT) In-Reply-To: References: From: Sam Date: Wed, 21 Jun 2017 15:22:45 +0800 Message-ID: To: Pavel Shirshov Cc: dev@dpdk.org, users@dpdk.org, qemu-devel@nongnu.org, qemu-discuss@nongnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] Will huge page have negative effect on guest vm in qemu enviroment? X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 07:22:47 -0000 Thank you~ 1. We have a compare test on qemu-kvm enviroment with huge page and without huge page. Qemu start process is much longer in huge page enviromwnt. And I write an email titled with '[DPDK-memory] how qemu waste such long time under dpdk huge page envriment?'. I could resend it later. 2. Then I have another test on qemu-kvm enviroment with huge page and without huge page, which I didn't start ovs-dpdk and vhostuser port in qemu start process. And I found Qemu start process is also much longer in huge page enviroment. So I think huge page enviroment, which grub2.cfg file is specified in =E2=80=98[DPDK-memory] how qemu waste such long time under dpdk huge page envriment?=E2=80=99, wil= l really have negative effect on qemu start up process. That's why we don't like to use ovs-dpdk. Althrough ovs-dpdk is faster, but the start up process of qemu is much longer then normal ovs, and the reason is nothing with ovs but huge page. For customers, vm start up time is important then network speed. BTW, ovs-dpdk start up process is also longer then normal ovs. But I know the reason, it's dpdk EAL init process with forking big continous memory and zero this memory. For qemu, I don't know why, as there is no log to report this. 2017-06-21 14:15 GMT+08:00 Pavel Shirshov : > Hi Sam, > > Below I'm saying about KVM. I don't have experience with vbox and others. > 1. I'd suggest don't use dpdk inside of VM if you want to see best > perfomance on the box. > 2. huge pages enabled globally will not have any bad effect to guest > OS. Except you have to enable huge pages inside of VM and provide real > huge page for VM's huge pages from the host system. Otherwise dpdk > will use "hugepages" inside of VM, but this "huge pages" will not real > ones. They will be constructed from normal pages outside. Also when > you enable huge pages OS will reserve them from start and your OS will > not able use them for other things. Also you can't swap out huge > pages, KSM will not work for them and so on. > 3. You can enable huge pages just for one numa node. It's impossible > to enable them just for one core. Usually you reserve some memory for > hugepages when the system starts and you can't use this memory in > normal applications unless normal application knows how to use them. > > Also why it didn't work inside of the docker? > > > On Tue, Jun 20, 2017 at 8:35 PM, Sam wrote: > > BTW, we also think about use ovs-dpdk in docker enviroment, but test > result > > said it's not good idea, we don't know why. > > > > 2017-06-21 11:32 GMT+08:00 Sam : > > > >> Hi all, > >> > >> We plan to use DPDK on HP host machine with several core and big memor= y. > >> We plan to use qemu-kvm enviroment. The host will carry 4 or more gues= t > vm > >> and 1 ovs. > >> > >> Ovs-dpdk is much faster then normal ovs, but to use ovs-dpdk, we have = to > >> enable huge page globally. > >> > >> My question is, will huge page enabled globally have negative effect o= n > >> guest vm's memory orperate or something? If it is, how to prevent this= , > or > >> could I enable huge page on some core or enable huge page for a part o= f > >> memory? > >> > >> Thank you~ > >> >