Skip site navigation (1)Skip section navigation (2)
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>