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>
index | next in thread | previous in thread | raw e-mail
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 their expected usage. Sometimes, applications can consume bit more than expected 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 it has to swap-out, consider these set of pages after everything else has been looked at. The hope is that some not-so-important application's pages get swapped and that would meet the paging requirements with touching the pages of "privileged" application. Thanks, Sushanth ________________________________ From: Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl> To: Edward Tomasz Napierała <trasz@FreeBSD.org> Cc: Sushanth Rai <sushanth_rai@yahoo.com>; "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Sent: Friday, April 25, 2014 4:59 AM Subject: Re: Priotizing pages to be swapped-out MADV_DONTNEED as well as MADV_SEQUENTIAL On Thu, 24 Apr 2014, Edward Tomasz Napierała wrote: > Wiadomość napisana przez Sushanth Rai w dniu 22 kwi 2014, o godz. 23:05: >> Is there any mechanism for a privileged user application to provide a hint to kernel to prioritize some user pages to be swapped-out later (after all the "lower" priority pages have been swapped-out) > > See madvise(2), perhaps? > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > 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%6 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, -Karlhelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1398449429.94001.YahooMailNeo>