Date: Fri, 25 Apr 2014 11:10:29 -0700 (PDT) From: Sushanth Rai <sushanth_rai@yahoo.com> To: Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl>, =?utf-8?B?RWR3YXJkIFRvbWFzeiBOYXBpZXJhxYJh?= <trasz@FreeBSD.org> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Priotizing pages to be swapped-out Message-ID: <1398449429.94001.YahooMailNeo@web181701.mail.ne1.yahoo.com> In-Reply-To: <alpine.BSF.2.00.1404251358290.30199@wojtek.tensor.gdynia.pl> References: <1398200734.20818.YahooMailNeo@web181703.mail.ne1.yahoo.com> <3FE8172F-057E-426E-9981-67A77B7FC352@FreeBSD.org> <alpine.BSF.2.00.1404251358290.30199@wojtek.tensor.gdynia.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <wojtek@wojtek.tensor.gdy= nia.pl>=0ATo: Edward Tomasz Napiera=C5=82a <trasz@FreeBSD.org> =0ACc: Susha= nth Rai <sushanth_rai@yahoo.com>; "freebsd-hackers@freebsd.org" <freebsd-ha= ckers@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: <owner-freebsd-hackers@FreeBSD.ORG> 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 <freebsd-hackers@freebsd.org>; 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 <freebsd-hackers@freebsd.org>; 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 <freebsd-hackers@freebsd.org>; Sat, 26 Apr 2014 11:30:26 +0100 (BST) Date: Sat, 26 Apr 2014 11:30:25 +0100 From: Karl Pielorz <kpielorz_lst@tdx.co.uk> To: freebsd-hackers@freebsd.org Subject: HAST performance / dtrace / _umtx_op Message-ID: <B044E9557B63332185C7792F@study64.tdx.co.uk> 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 <freebsd-hackers.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-hackers>, <mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers/> List-Post: <mailto:freebsd-hackers@freebsd.org> List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, <mailto:freebsd-hackers-request@freebsd.org?subject=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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1398449429.94001.YahooMailNeo>