From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 25 18:12:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07B2EB6D for ; Fri, 25 Apr 2014 18:12:14 +0000 (UTC) Received: from nm1-vm1.access.bullet.mail.gq1.yahoo.com (nm1-vm1.access.bullet.mail.gq1.yahoo.com [216.39.62.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BF7451508 for ; Fri, 25 Apr 2014 18:12:13 +0000 (UTC) Received: from [216.39.60.171] by nm1.access.bullet.mail.gq1.yahoo.com with NNFMP; 25 Apr 2014 18:10:30 -0000 Received: from [216.39.60.233] by tm7.access.bullet.mail.gq1.yahoo.com with NNFMP; 25 Apr 2014 18:10:30 -0000 Received: from [127.0.0.1] by omp1004.access.mail.gq1.yahoo.com with NNFMP; 25 Apr 2014 18:10:30 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 477733.45298.bm@omp1004.access.mail.gq1.yahoo.com Received: (qmail 35736 invoked by uid 60001); 25 Apr 2014 18:10:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1398449429; bh=V/WVprndHhoZwBGPOXk7p3j2UpISFWlGseSnwzcZCkM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=AWwMMzeH+AeXcnOV3BB8CBxT7neUJdv4dLpub6ICWrF+Ezu+yojfqzKKnHZ3VLRyAKKU+UnM9FvcNUkftNmHTWUu+LXMuF08fShG5Q/HtjNkbJ8g2RNON1SSmKAITVP39vN3Sg3GKvHy62+WpgnLhvAU8yiAsfMiLmZZg7xKqHk= X-YMail-OSG: vejnR6EVM1mHhuHaGDfoZ3rU.kASllOuZ.ve4d2EUtnsZNs Jj4KGIvG4o0Zx8AUNaK6IjHF.Ae0XFrOdvDOKFCSzAbdzh_ozCEghUr9bQgu FvUw8FoX1q_8UPbA.Hgr39idD_.yAFkWOu5Gr0WDtkc8BICGdY8YVy_Vn9yY H8ITGdY9qO5AfQuqUjNDl4E6mGQXGqNFhAlPDlv52D8N67LkVDS9Scfn9ys7 QiwaJEpyxENMu75M22691rv2vkXHzmJOwAGLvkVqi7lDUCJ5_juz3BcAHWri W22ZrfrKTLZTjXGfVGRN30ZGwBAt4ykm9DK4p3uvRSHSlr7BmwZpzjA6FPiC I5J6rf0tffLd4Zf8f95ym.1HTDFUuklPmDb6bFViCZ4hLU2nVNw6WT_i3YDY ywkVb2I5mBQzVqhRR6HFg1Dil8WW6de9DwLnqgOleDXbh4IaCoWy2cKqmNNL rcU3XL86X_A5S_UWV1EpN0loINde7SsVa8FPGk2Lcmhx5cCai_bGOPUsVntP HrARI7JAfI0u7CYS6m2riMYR5ezJ7o5VHD6hn.LRe9Vhv7Av7NLQi5tk- Received: from [76.211.233.136] by web181701.mail.ne1.yahoo.com via HTTP; Fri, 25 Apr 2014 11:10:29 PDT X-Rocket-MIMEInfo: 002.001, SSBsb29rZWQgYXQgdGhlc2UgYnV0IHRoZXkgZG9uJ3QgcXVpdGUgbWF0Y2ggd2hhdCBJJ20gaG9waW5nIGZvci4gQmFzaWNhbGx5LCBpbiBvdXIgc3lzdGVtIHdlIHNvZnQgcGFydGl0aW9uIHRoZSBtZW1vcnkgYW1vbmcgYXBwbGljYXRpb25zIGJhc2VkIG9uIHRoZWlyIGV4cGVjdGVkIHVzYWdlLiBTb21ldGltZXMsIGFwcGxpY2F0aW9ucyBjYW4gY29uc3VtZSBiaXQgbW9yZSB0aGFuIGV4cGVjdGVkIGFuZCB3ZSBlbmQgdXAgc3dhcHBpbmcsIHdoaWNoIGlzIG9rYXkuIFNob3J0IG9mIG1sb2NrJ2luZyB0aGUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.185.657 References: <1398200734.20818.YahooMailNeo@web181703.mail.ne1.yahoo.com> <3FE8172F-057E-426E-9981-67A77B7FC352@FreeBSD.org> Message-ID: <1398449429.94001.YahooMailNeo@web181701.mail.ne1.yahoo.com> Date: Fri, 25 Apr 2014 11:10:29 -0700 (PDT) From: Sushanth Rai Subject: Re: Priotizing pages to be swapped-out To: Wojciech Puchar , =?utf-8?B?RWR3YXJkIFRvbWFzeiBOYXBpZXJhxYJh?= In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Sushanth Rai List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 18:12:14 -0000 I looked at these but they don't quite match what I'm hoping for. Basically= , in our system we soft partition the memory among applications based on th= eir expected usage. Sometimes, applications can consume bit more than expec= ted and we end up swapping, which is okay. Short of mlock'ing the memory, I= was looking for a way where an application can advise the kernel that if i= t has to swap-out, consider these set of pages after everything else has be= en looked at. The hope is that some not-so-important application's pages ge= t swapped and that would meet the paging requirements with touching the pag= es of "privileged" application.=0A=0AThanks,=0ASushanth=0A=0A=0A=0A________= ________________________=0A From: Wojciech Puchar =0ATo: Edward Tomasz Napiera=C5=82a =0ACc: Susha= nth Rai ; "freebsd-hackers@freebsd.org" =0ASent: Friday, April 25, 2014 4:59 AM=0ASubject: Re: P= riotizing pages to be swapped-out=0A =0A=0AMADV_DONTNEED=0A=0Aas well as MA= DV_SEQUENTIAL=0A=0A=0A=0AOn Thu, 24 Apr 2014, Edward Tomasz Napiera=C5=82a = wrote:=0A=0A> Wiadomo=C5=9B=C4=87 napisana przez Sushanth Rai w dniu 22 kwi= 2014, o godz. 23:05:=0A>> Is there any mechanism for a privileged user app= lication to provide a hint to kernel to prioritize some user pages to be sw= apped-out later (after all the "lower" priority pages have been swapped-out= )=0A>=0A> See madvise(2), perhaps?=0A>=0A> ________________________________= _______________=0A> freebsd-hackers@freebsd.org mailing list=0A> http://lis= ts.freebsd.org/mailman/listinfo/freebsd-hackers=0A> To unsubscribe, send an= y mail to "freebsd-hackers-unsubscribe@freebsd.org"=0A>=0A> From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 26 10:30:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3A8EFE0C for ; Sat, 26 Apr 2014 10:30:34 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id D85891BB5 for ; Sat, 26 Apr 2014 10:30:33 +0000 (UTC) Received: from study64.tdx.co.uk (study64.tdx.co.uk [62.13.130.231]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s3QAUPqZ034471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 26 Apr 2014 11:30:26 +0100 (BST) Date: Sat, 26 Apr 2014 11:30:25 +0100 From: Karl Pielorz To: freebsd-hackers@freebsd.org Subject: HAST performance / dtrace / _umtx_op Message-ID: X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 10:30:34 -0000 Hi All, I've been looking at HAST recently - and noticed there's a huge performance hit (on 10-STABLE anyway) even if you setup a disk with a remote of 'none' - switching from the 'raw' disk to '/dev/hast/disk' shows a 50% performance hit [in testing having an active secondary via 10Gbit link doesn't seem to show any further performance drop]. Thinking of digging deeper I setup a single disk HAST system (with no remote node) and ran dtrace on the daemon handling that disk. I then DD'ed 1Gbyte of data to that disk. The output from dtrace shows: " Elapsed Times for PID 5219, SYSCALL TIME (ns) pread 4439902 pwrite 7617448542 ioctl 11370282332 sigtimedwait 20015976362 _umtx_op 36514993910 " To my untrained eye that looks like it spent more time on locking than anything else? - Followed by ioctl's - then, considerably less time on pread/pwrite (which must be the bit that's copying the data) Presumably the time spent in sigtimedwait would have actually been 'waiting' time - i.e. not active CPU usage kind of time? Does that seem to be the case? - At least then I'll hopefully have some pointer where to look further for why there's such a performance hit. Thanks, -Karl