From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 8 07:11:26 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CE0CF106566B for ; Sun, 8 Apr 2012 07:11:26 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 851828FC0A for ; Sun, 8 Apr 2012 07:11:26 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1SGmHV-000DA5-DC for freebsd-hackers@freebsd.org; Sun, 08 Apr 2012 10:11:25 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 08 Apr 2012 10:11:25 +0300 From: Daniel Braniss Message-ID: Subject: time stops in vmware X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 07:11:26 -0000 Hi All There was some mention before that time stops under vmware, and now it's happened to me :-) the clock stopped now, the system is responsive, but eg sleep 1 never finishes. Is there a solution? btw, I'm running 8.2-stable, i'll try 8.3 soon. danny From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 8 13:08:51 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CCC10106566C; Sun, 8 Apr 2012 13:08:51 +0000 (UTC) (envelope-from nec556@retena.com) Received: from resmaa12.ono.com (smtp12.ono.com [62.42.230.20]) by mx1.freebsd.org (Postfix) with ESMTP id 638B78FC1B; Sun, 8 Apr 2012 13:08:50 +0000 (UTC) Received: from GogPortatil.retena.com (37.11.170.63) by resmaa12.ono.com (8.5.113) (authenticated as nec556@retena.com) id 4EFDA3B5017E0D89; Sun, 8 Apr 2012 15:08:49 +0200 Message-ID: <4EFDA3B5017E0D89@> (added by postmaster@resmaa12.ono.com) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 08 Apr 2012 15:10:17 +0200 To: Ivan Voras From: Eduardo Morras In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Antivirus: AVG for E-mail 2012.0.1913 [2411/4921] Cc: freebsd-hackers@freebsd.org Subject: Re: Socket buffer usage X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 13:08:51 -0000 At 23:16 07/04/2012, you wrote: >Hi, > >I'm tracking down an obscure bug in my userland program and it might >have something to do with the way I write&read data through a (Unix >domain) socket. I'm setting SO_SNDBUF and SO_RCVBUF, and what I'm >looking for is some way to query the amount of TX & RX buffered / free >data on a socket. Is there something I can use? I'll even accept >inspecting kernel structures if explained in detail and can be done on >a running system. > >Alternatively, is there anything else which could cause poll(2) with >POLLOUT on a socket to return no events ready on such a socket? (my >expectation being that a socket is always ready to be written to if >there is buffer space free...). Setting fd to -1 in pollfd struct resets revents. Perhaps you have not setted fd properly. >_______________________________________________ >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 Sun Apr 8 13:41:30 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BE5591065670; Sun, 8 Apr 2012 13:41:30 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0193F8FC0C; Sun, 8 Apr 2012 13:41:29 +0000 (UTC) Received: by lbok6 with SMTP id k6so1943216lbo.13 for ; Sun, 08 Apr 2012 06:41:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :content-language:thread-index; bh=CkTa1+W33Z7HndciDTgTAbgkmDil8lm0ME/4IyPGnQU=; b=btEjIsuLwqotaT3D5vBx98V/bcmlRU7BpkLy0IYhuUAKvzAlwy9mmu1uyN8aUmMYc4 Zoy1lEvvc/AAOMHBBm6OV85PpJ4I/tZQqbaJGoAH+cad9gN+Z7ESKexkjEKepWT0PLeG sdl9SrW1zsFKfE7bbMEM7JVXwXYrgnnyjPMEJAxIvNPPAw9uLbwTa8BPfO+P9GM9RJyc RSxkYR61xLDx3b4vDgYkn9z5dAaho8/odzcRWR7qh/x0AxRna93jleYULttaZS2W5vaw GKVtIsH8oH6JOnw2pNedtShFNDSMB9SQZ6LhGZdxt9E/iEHzJgWbxWmXKG6TW+9R0R6F Clig== Received: by 10.152.130.167 with SMTP id of7mr6608331lab.36.1333892488619; Sun, 08 Apr 2012 06:41:28 -0700 (PDT) Received: from rimwks1w7x64 ([164.215.86.96]) by mx.google.com with ESMTPS id tt8sm17322871lbb.16.2012.04.08.06.41.25 (version=SSLv3 cipher=OTHER); Sun, 08 Apr 2012 06:41:27 -0700 (PDT) From: rozhuk.im@gmail.com To: "'Ivan Voras'" , "'freebsd-hackers'" References: In-Reply-To: Date: Sun, 8 Apr 2012 22:41:16 +0900 Message-ID: <4f819587.a894700a.4590.2270@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: ru Thread-Index: Ac0VA+9z4k7SF2RvRR2SiokpMS+4ogAiVOSg Cc: Subject: RE: Socket buffer usage X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rozhuk.IM@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 13:41:30 -0000 ioctl(FIONREAD) > -----Original Message----- > From: owner-freebsd-hackers@freebsd.org [mailto:owner-freebsd- > hackers@freebsd.org] On Behalf Of Ivan Voras > Sent: Sunday, April 08, 2012 6:17 AM > To: freebsd-hackers > Subject: Socket buffer usage > > Hi, > > I'm tracking down an obscure bug in my userland program and it might > have something to do with the way I write&read data through a (Unix > domain) socket. I'm setting SO_SNDBUF and SO_RCVBUF, and what I'm > looking for is some way to query the amount of TX & RX buffered / free > data on a socket. Is there something I can use? I'll even accept > inspecting kernel structures if explained in detail and can be done on > a running system. > > Alternatively, is there anything else which could cause poll(2) with > POLLOUT on a socket to return no events ready on such a socket? (my > expectation being that a socket is always ready to be written to if > there is buffer space free...). > _______________________________________________ > 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 Sun Apr 8 19:35:14 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D47E1065679 for ; Sun, 8 Apr 2012 19:35:14 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 455E68FC17 for ; Sun, 8 Apr 2012 19:35:14 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so4389811pbc.13 for ; Sun, 08 Apr 2012 12:35:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=o5/sSKgaVl2naTNCdjqLj6aS0mHiXzsnbQ9URIEj9+k=; b=xaNNVLpDX3OQHVl4Dc5t7QkEQSoXo16wrWczOo+YumWuIafZqfMX5J+qxOp5v3JxJF m5c5roUX7puB4JhOgqPbquvni9zDdJ4n2t12+h3kDsJrpise197ylZbPV2s+EQBjOxGy GQCqeyVea+p9Nkj+hD6XpyEYCHiWG5u3MAz2SIdI20P4xuXUNbMaHaUVTh8h1VP5X+td fdo2JpTjISG0epV0qqaZPOhjU6AvoUfXKjo5oqR8CueUrEQMkl25KJgu0Ge9tpT2ricH tb21wMBr8b9LSCNGfYAFeZ4Fhp9zcFvqkxx8vrt/zm86kQZ3k7TdqGhO3IABH/ktqW65 ny1g== MIME-Version: 1.0 Received: by 10.68.229.33 with SMTP id sn1mr13716224pbc.59.1333913708305; Sun, 08 Apr 2012 12:35:08 -0700 (PDT) Received: by 10.68.66.138 with HTTP; Sun, 8 Apr 2012 12:35:08 -0700 (PDT) Date: Sun, 8 Apr 2012 15:35:08 -0400 Message-ID: From: Super Bisquit To: FreeBSD Hackers Content-Type: text/plain; charset=ISO-8859-1 Subject: Exporting environment from Linux to FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 19:35:14 -0000 http://docs.freebsd.org/cgi/getmsg.cgi?fetch=89377+0+archive/2008/freebsd-java/20080203.freebsd-java is the template given for me to follow. I have Debian running on an iMac G4 and FreeBSD running on a QuickSilver G4. 1. The assumption is that the script is ran on the iMac. Considering that SSH between both machines is set up, is the exporting: a) From the iMac to the QuickSilver. b) The inverse of the above. And c) Is it ran from the same terminal used for the SSH login d) Or from another terminal connected on the target to the SSHed login? If the exporting is done such as stated in d above, then how do I set that up properly? Also, does the shell type in the original environment need to match the shell of the target environment or is it an irrelevant point? I'm using the standard ssh user@ for logins. If the method to use is NFS with a and b being replaced with the NFS variables- being both server and client, then which similar method is the correct one? Is the script setup in /usr/share/java, /usr/lib/java, or both? Thanks. From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 8 19:55:11 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 39CBB1065670 for ; Sun, 8 Apr 2012 19:55:11 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id C504A8FC0C for ; Sun, 8 Apr 2012 19:55:10 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SGyCW-0004Sy-7U for freebsd-hackers@freebsd.org; Sun, 08 Apr 2012 21:55:04 +0200 Received: from c-82-209-158-57.cust.bredband2.com ([82.209.158.57]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 08 Apr 2012 21:55:04 +0200 Received: from mc by c-82-209-158-57.cust.bredband2.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 08 Apr 2012 21:55:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Michael Cardell Widerkrantz Date: Sun, 08 Apr 2012 21:45:57 +0200 Organization: Temple of the Moby Hack Lines: 140 Message-ID: <86ipha2eiy.fsf@totoro.hack.org> References: <4F55A0EA.8000300@gmail.com> <4f5635d4.5Qp6ViEgiFLUuPKI%perryh@pluto.rain.com> Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: c-82-209-158-57.cust.bredband2.com User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/23.4 (berkeley-unix) Cancel-Lock: sha1:P1PZFPJbsLtg3hB4piCOfuN/TkA= Subject: Re: Graphical Terminal Environment X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 19:55:11 -0000 Since Brandon started this in a sort of rambling mood I'm keeping up with the tradition... This is just what's on top of my mind right now. perryh@pluto.rain.com, 2012-03-06 17:05 (+0100): > I _think_ SunTools/SunView were proprietary, Absolutely. > although it's possible that Sun released the source code at some > point. Much of the actual window system in SunView was implemented in the kernel, IIRC. That might not be interesting in this case. Another system I used on quite memory-starved Sun 3/50s (as little as 4 meg) and 3/60s and later on SPARCstations, was the Bellcore MGR window system: http://hack.org/mc/mgr/ http://en.wikipedia.org/wiki/ManaGeR Many users in the Lysator academic computing society where I first met MGR preferred it to SunView. It was really nice on monochrome monitors at 1152x900. It's also network transparent so you can run remote graphics applications. MGR was ported to a lot of systems, including FreeBSD. It might still compile, but it's unlikely to support anything higher than 640x480 on FreeBSD. If anyone tries to compile it and runs into problems I might be able to help. Just e-mail me. To support higher resolutions on FreeBSD Brandon would have to rewrite the functions in libbitblit. One way to do it would be to use vgl(3) to implement the libbitblit functions. Should be pretty straightforward, I think, and not too much work. On the other hand vgl(3) probably only supports VESA so Brandon will still have to write a special libbitblit for the nvidia card he mentions. MGR doesn't tile windows but Brandon might want to add a mode to do that. MGR has a slightly bothersome license, though, forbidding commercial sales so this might not be the best way forward. On Sun SPARCs under SunOS it was also possible to run a tiling window system called Oberon. It shares its name with a programming language and a complete native operating system. Oberon is a complete environment using the Oberon programming language so it might not be what Brandon wants but it might be interesting to look at nonetheless. I believe Oberon is still available and can run either as a native operating system or as an environment under other systems. The SPARC port I used many years ago was running under SunOS but was running directly on the console. I don't know if there are any modern Oberon systems that can do that. Incidentally, Oberon was one of the inspirations behind Rob Pike's acme editor on Plan 9. Acme, however, just handles text. Oberon does graphics as well. I've been thinking something along the same lines as Brandon for several years now: to write a lightweight window system. For many years I resisted X and kept using MGR, even going so far as porting MGR to Solaris and to Linux/SPARC just to be able to keep using MGR on more modern systems. I gave up, I think, around 1994. If I would do it again I would probably not work on MGR but I might use it for some ideas. One thing that MGR does that I wouldn't do was to force all graphics operations to be done through escape codes in terminal windows. While it might be great for network transparance it's not so great for the speed of local programs. The Wayland project is interesting but seems very Linux oriented. On the other hand work on KMS/GEM support on FreeBSD is coming along. It might be possible to get Wayland running on FreeBSD. I haven't looked into it myself (yet). James Gosling, who wrote both the Andrew window system and Sun's NeWS (not SunView, the *other* Sun window system, the one with a Postscript interpreter) has written an interesting paper about window system design. I have a copy here: http://hack.org/mc/texts/gosling-wsd.pdf Some people have mentioned Plan 9's 8 1/2 and rio. They are both very interesting window systems. While I think they have a very clean design I think they might be problematic to implement in a system other than Plan 9. You see, both 8 1/2 and rio are *file servers*. They make heavy use of the fact that the namespace of files in Plan 9 is local to processes. Reading from /dev/mouse from a process under 8 1/2, for instance, means listening to mouse events in the window that process is running in. Another process has a *completely separate* /dev/mouse file but is using *the same name*. Neat, but not very portable. I've used 8 1/2 many years ago but haven't used rio. I believe the difference between them is fairly small, but I might be wrong: I think rio allows the process to write pixels directly to a window while 8 1/2 uses special commands written to /dev/bitblt. Right? Rob Pike, the author of both 8 1/2 and rio, also wrote several earlier window systems that are interesting, for intance mtx and mux on the Blit and its decendants, the AT&T Teletype 5620 DMD, AT&T 630 and 730. Some software for these terminals/light workstations is still available. See: http://www.brouhaha.com/~eric/retrocomputing/att/5620/ An entertainging video featuring Pike and the Blit is available here: http://www.youtube.com/watch?v=waTL1abCm9I Notice that they really felt the need to explain how a mouse works. Alright, this was 1982. An interesting idea I've been thinking about is making a new window system API at least partially compatible with either MGR's API (not the escape codes - the C functions) or the AT&T terminal's API, or perhaps making a compatibility library. This way a lot of fairly nice very lightweight software like troff previewers et cetera would be available from the start. Is this a waste of time? I don't know. For instance X11 on the grownup smartphone I use right now, an ARM based netbook from Genesi, is nice to have but there's very limited memory on the box and I would rather use the memory for something else. One of my thin clients, an HP t5125 from 2005, has even less memory: 128 MiB soldered on the motherboard. It still makes a quite nice diskless workstation but with a more lightweight window system it would be nicer still. I think there are many such boxen around that might still be useful. Happy hacking, MC -- MC, http://hack.org/mc/ From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 8 20:07:35 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3F59106564A for ; Sun, 8 Apr 2012 20:07:35 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5E8E88FC15 for ; Sun, 8 Apr 2012 20:07:35 +0000 (UTC) Received: by ggnk4 with SMTP id k4so2003564ggn.13 for ; Sun, 08 Apr 2012 13:07:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=caCXFDRnDZ+wI0YYF9WPLb4XfFrN8D2rC5J5zBr+6jM=; b=OEFe5Q91M/mC7bK6fIcsaNfThSjlOu9zKFkbSoAJq+q6P/Z1+kZbSD1ZtEQX91rZuC uggdz/tZbJr5TLkMR2gyPYkN3+9Was8VIHcpFbT/6fglaRhKWFlFvhjlkeu9D7Cyvwq0 PAgWHFUtlTAsEPFlrrGo+CwEXiWNeA2nv2u1i2HvEp7rVVaApC5R946mzT4kKuO9Mq2z o8A74j/cGVHLRz8p8QNiMWrS7ZB+QaoMSy/8nXnlh0ujB9twePSIXrCNPDblJlbz8EkM YLRKasH0GUXQClcT9hCRCXKUlXjxjORNkSetnDQqsvyPJ9g4I+eWPgNFP8edyp7wnOou yGqw== Received: by 10.101.6.8 with SMTP id j8mr1248660ani.10.1333915654577; Sun, 08 Apr 2012 13:07:34 -0700 (PDT) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.100.3.20 with HTTP; Sun, 8 Apr 2012 13:06:53 -0700 (PDT) In-Reply-To: <4f819587.a894700a.4590.2270@mx.google.com> References: <4f819587.a894700a.4590.2270@mx.google.com> From: Ivan Voras Date: Sun, 8 Apr 2012 22:06:53 +0200 X-Google-Sender-Auth: nI_qy5bQE706fitX6OL9pHwP8JA Message-ID: To: Rozhuk.IM@gmail.com Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers Subject: Re: Socket buffer usage X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 20:07:35 -0000 On 8 April 2012 15:41, wrote: > ioctl(FIONREAD) Yes, this is what I was looking for, thanks! From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 9 03:51:19 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5A761065670 for ; Mon, 9 Apr 2012 03:51:19 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mail2.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by mx1.freebsd.org (Postfix) with ESMTP id A38848FC0A for ; Mon, 9 Apr 2012 03:51:19 +0000 (UTC) Received: from localhost (pool-74-102-30-128.nwrknj.fios.verizon.net [74.102.30.128]) by mail2.asahi-net.or.jp (Postfix) with ESMTP id 99DD5130393 for ; Mon, 9 Apr 2012 12:33:32 +0900 (JST) Date: Sun, 8 Apr 2012 23:33:24 -0400 From: Yoshihiro Ota To: freebsd-hackers@freebsd.org Message-Id: <20120408233324.77d24491.ota@j.email.ne.jp> In-Reply-To: References: <0D2E65B3D0AB4A6483C26A613FC73F83@dudu.ro> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.5; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Socket buffer usage X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 03:51:19 -0000 On Sun, 8 Apr 2012 01:01:01 +0200 Ivan Voras wrote: > On 7 April 2012 23:36, Vlad Galu wrote: > > This might not exactly be what you want, but struct kevent has a member called "data" which, > > for sockets and pipes, returns the number of available bytes to read (or write) for EVFILT_READ > > (or EVFILT_WRITE) events. > > > > That's a good idea but I'm actually trying to find out why my write > events are not firing, so I can't get to that information. Do you happen to use 2 TCP connections in threaded client/server programs: one for reading only and the other for writing only? If so, I observed such behavior in several years ago and can give you a hint. Hiro From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 9 07:18:00 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BC2451065674 for ; Mon, 9 Apr 2012 07:18:00 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 30E5B8FC15 for ; Mon, 9 Apr 2012 07:18:00 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so4060917bkc.13 for ; Mon, 09 Apr 2012 00:17:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=PJqSoEtNzm82n7T4ClS3bAUIxz420nUVYlErTJZfLsU=; b=DCZaB41q9LC5i+DWEkv0StxMy6ZDGdhSsgXxkzUPcMiL4meypp0kXTtEmd5gUvsd2k Q3uw9e7WCxFPXf9L+bCPFcbrDiNFCkpAPCLInJSMUjn+skU4NWXsE+0JfqlPXnMlgTwe PMUO05ykTsU+TcUsT94Wmj0bRYL4DRx/reYfOnqwagTu/BNBk8nxlejEgjt2GjDLOqfv 8u0RWjMd5yUe9hIve6CdJIu1uLn4rIajrpAOGowzG2hTkYbUFgmSG2EYi2mVnaV6pr40 M9FTOcF3zzsjpFUbZmVmFBIZceNoZJFmv4uB21+l73g7R1dpkaLdifaL4yRxcGYcoje+ MNiA== Received: by 10.205.133.13 with SMTP id hw13mr2682024bkc.25.1333955878978; Mon, 09 Apr 2012 00:17:58 -0700 (PDT) Received: from [10.254.254.77] (ppp109-252-209-10.pppoe.spdop.ru. [109.252.209.10]) by mx.google.com with ESMTPS id gw19sm25272347bkc.8.2012.04.09.00.17.42 (version=SSLv3 cipher=OTHER); Mon, 09 Apr 2012 00:17:44 -0700 (PDT) Message-ID: <4F828D15.8080604@zonov.org> Date: Mon, 09 Apr 2012 11:17:41 +0400 From: Andrey Zonov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Konstantin Belousov References: <4F7B495D.3010402@zonov.org> <20120404071746.GJ2358@deviant.kiev.zoral.com.ua> <4F7DC037.9060803@rice.edu> <4F7DF39A.3000500@zonov.org> <20120405194122.GC2358@deviant.kiev.zoral.com.ua> <4F7DF88D.2050907@zonov.org> <20120406081349.GE2358@deviant.kiev.zoral.com.ua> In-Reply-To: <20120406081349.GE2358@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmuBpUwjYu/nwIz/E/X4WZ3wf+xD5Z7cqRvrv3lgRl/kkAe6e3AtRIJE5XZaS6EwRD5zGaL Cc: alc@freebsd.org, freebsd-hackers@freebsd.org, Alan Cox Subject: Re: problems with mmap() and disk caching X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 07:18:00 -0000 On 06.04.2012 12:13, Konstantin Belousov wrote: > On Thu, Apr 05, 2012 at 11:54:53PM +0400, Andrey Zonov wrote: >> On 05.04.2012 23:41, Konstantin Belousov wrote: >>> On Thu, Apr 05, 2012 at 11:33:46PM +0400, Andrey Zonov wrote: >>>> On 05.04.2012 19:54, Alan Cox wrote: >>>>> On 04/04/2012 02:17, Konstantin Belousov wrote: >>>>>> On Tue, Apr 03, 2012 at 11:02:53PM +0400, Andrey Zonov wrote: >>>> [snip] >>>>>>> This is what I expect. But why this doesn't work without reading file >>>>>>> manually? >>>>>> Issue seems to be in some change of the behaviour of the reserv or >>>>>> phys allocator. I Cc:ed Alan. >>>>> >>>>> I'm pretty sure that the behavior here hasn't significantly changed in >>>>> about twelve years. Otherwise, I agree with your analysis. >>>>> >>>>> On more than one occasion, I've been tempted to change: >>>>> >>>>> pmap_remove_all(mt); >>>>> if (mt->dirty != 0) >>>>> vm_page_deactivate(mt); >>>>> else >>>>> vm_page_cache(mt); >>>>> >>>>> to: >>>>> >>>>> vm_page_dontneed(mt); >>>>> >>>> >>>> Thanks Alan! Now it works as I expect! >>>> >>>> But I have more questions to you and kib@. They are in my test below. >>>> >>>> So, prepare file as earlier, and take information about memory usage >>> >from top(1). After preparation, but before test: >>>> Mem: 80M Active, 55M Inact, 721M Wired, 215M Buf, 46G Free >>>> >>>> First run: >>>> $ ./mmap /mnt/random >>>> mmap: 1 pass took: 7.462865 (none: 0; res: 262144; super: >>>> 0; other: 0) >>>> >>>> No super pages after first run, why?.. >>>> >>>> Mem: 79M Active, 1079M Inact, 722M Wired, 216M Buf, 45G Free >>>> >>>> Now the file is in inactive memory, that's good. >>>> >>>> Second run: >>>> $ ./mmap /mnt/random >>>> mmap: 1 pass took: 0.004191 (none: 0; res: 262144; super: >>>> 511; other: 0) >>>> >>>> All super pages are here, nice. >>>> >>>> Mem: 1103M Active, 55M Inact, 722M Wired, 216M Buf, 45G Free >>>> >>>> Wow, all inactive pages moved to active and sit there even after process >>>> was terminated, that's not good, what do you think? >>> Why do you think this is 'not good' ? You have plenty of free memory, >>> there is no memory pressure, and all pages were referenced recently. >>> THere is no reason for them to be deactivated. >>> >> >> I always thought that active memory this is a sum of resident memory of >> all processes, inactive shows disk cache and wired shows kernel itself. > So you are wrong. Both active and inactive memory can be mapped and > not mapped, both can belong to vnode or to anonymous objects etc. > Active/inactive distinction is only the amount of references that was > noted by pagedaemon, or some other page history like the way it was > unwired. > > Wired is not neccessary means kernel-used pages, user processes can > wire their pages as well. Let's talk about that in details. My understanding is the following: Active memory: the memory which is referenced by application. An application may get memory only through mmap() (allocator don't use brk()/sbrk() any more). The resident memory of an application is the sum of physical used memory. So, sum of RSS is active memory. Inactive memory: the memory which has no references. Once we call read() on the file, the file is in inactive memory, because we have no references to this object, we just read it. This is also released memory by free(). Cache memory: I don't know what is it. It's always small enough to not think about it. Wired memory: kernel memory and yes, application may get wired memory through mlock()/mlockall(), but I haven't seen any real application which calls mlock(). >> >>>> >>>> Read the file: >>>> $ cat /mnt/random> /dev/null >>>> >>>> Mem: 79M Active, 55M Inact, 1746M Wired, 1240M Buf, 45G Free >>>> >>>> Now the file is in wired memory. I do not understand why so. >>> You do use UFS, right ? >> >> Yes. >> >>> There is enough buffer headers and buffer KVA >>> to have buffers allocated for the whole file content. Since buffers wire >>> corresponding pages, you get pages migrated to wired. >>> >>> When there appears a buffer pressure (i.e., any other i/o started), >>> the buffers will be repurposed and pages moved to inactive. >>> >> >> OK, how can I get amount of disk cache? > You cannot. At least I am not aware of any counter that keeps track > of the resident pages belonging to vnode pager. > > Buffers should not be thought as disk cache, pages cache disk content. > Instead, VMIO buffers only provide bread()/bwrite() compatible interface > to the page cache (*) for filesystems. > (*) - The cache term is used in generic term, not to confuse with > cached pages counter from top etc. > Yes, I know that. I try once again to ask my question about buffers. Is this reasonable to use for them 10% of the physical memory or we may set rational upper limit automatically? >> >>>> >>>> Could you please give me explanation about active/inactive/wired memory? >>>> >>>> >>>>> because I suspect that the current code does more harm than good. In >>>>> theory, it saves activations of the page daemon. However, more often >>>>> than not, I suspect that we are spending more on page reactivations than >>>>> we are saving on page daemon activations. The sequential access >>>>> detection heuristic is just too easily triggered. For example, I've seen >>>>> it triggered by demand paging of the gcc text segment. Also, I think >>>>> that pmap_remove_all() and especially vm_page_cache() are too severe for >>>>> a detection heuristic that is so easily triggered. >>>>> >>>> [snip] >>>> >>>> -- >>>> Andrey Zonov >> >> -- >> Andrey Zonov -- Andrey Zonov From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 9 09:18:56 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0084A106564A; Mon, 9 Apr 2012 09:18:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 4EDEB8FC08; Mon, 9 Apr 2012 09:18:54 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q399IfIC091846; Mon, 9 Apr 2012 12:18:41 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q399Ifl2001983; Mon, 9 Apr 2012 12:18:41 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q399IefW001982; Mon, 9 Apr 2012 12:18:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 9 Apr 2012 12:18:39 +0300 From: Konstantin Belousov To: Andrey Zonov Message-ID: <20120409091839.GH2358@deviant.kiev.zoral.com.ua> References: <4F7B495D.3010402@zonov.org> <20120404071746.GJ2358@deviant.kiev.zoral.com.ua> <4F7DC037.9060803@rice.edu> <4F7DF39A.3000500@zonov.org> <20120405194122.GC2358@deviant.kiev.zoral.com.ua> <4F7DF88D.2050907@zonov.org> <20120406081349.GE2358@deviant.kiev.zoral.com.ua> <4F828D15.8080604@zonov.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Iby4wbbvBBYJWhzT" Content-Disposition: inline In-Reply-To: <4F828D15.8080604@zonov.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: alc@freebsd.org, freebsd-hackers@freebsd.org, Alan Cox Subject: Re: problems with mmap() and disk caching X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 09:18:56 -0000 --Iby4wbbvBBYJWhzT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 09, 2012 at 11:17:41AM +0400, Andrey Zonov wrote: > On 06.04.2012 12:13, Konstantin Belousov wrote: > >On Thu, Apr 05, 2012 at 11:54:53PM +0400, Andrey Zonov wrote: > >>On 05.04.2012 23:41, Konstantin Belousov wrote: > >>>On Thu, Apr 05, 2012 at 11:33:46PM +0400, Andrey Zonov wrote: > >>>>On 05.04.2012 19:54, Alan Cox wrote: > >>>>>On 04/04/2012 02:17, Konstantin Belousov wrote: > >>>>>>On Tue, Apr 03, 2012 at 11:02:53PM +0400, Andrey Zonov wrote: > >>>>[snip] > >>>>>>>This is what I expect. But why this doesn't work without reading f= ile > >>>>>>>manually? > >>>>>>Issue seems to be in some change of the behaviour of the reserv or > >>>>>>phys allocator. I Cc:ed Alan. > >>>>> > >>>>>I'm pretty sure that the behavior here hasn't significantly changed = in > >>>>>about twelve years. Otherwise, I agree with your analysis. > >>>>> > >>>>>On more than one occasion, I've been tempted to change: > >>>>> > >>>>>pmap_remove_all(mt); > >>>>>if (mt->dirty !=3D 0) > >>>>>vm_page_deactivate(mt); > >>>>>else > >>>>>vm_page_cache(mt); > >>>>> > >>>>>to: > >>>>> > >>>>>vm_page_dontneed(mt); > >>>>> > >>>> > >>>>Thanks Alan! Now it works as I expect! > >>>> > >>>>But I have more questions to you and kib@. They are in my test below. > >>>> > >>>>So, prepare file as earlier, and take information about memory usage > >>>>from top(1). After preparation, but before test: > >>>>Mem: 80M Active, 55M Inact, 721M Wired, 215M Buf, 46G Free > >>>> > >>>>First run: > >>>>$ ./mmap /mnt/random > >>>>mmap: 1 pass took: 7.462865 (none: 0; res: 262144; super: > >>>>0; other: 0) > >>>> > >>>>No super pages after first run, why?.. > >>>> > >>>>Mem: 79M Active, 1079M Inact, 722M Wired, 216M Buf, 45G Free > >>>> > >>>>Now the file is in inactive memory, that's good. > >>>> > >>>>Second run: > >>>>$ ./mmap /mnt/random > >>>>mmap: 1 pass took: 0.004191 (none: 0; res: 262144; super: > >>>>511; other: 0) > >>>> > >>>>All super pages are here, nice. > >>>> > >>>>Mem: 1103M Active, 55M Inact, 722M Wired, 216M Buf, 45G Free > >>>> > >>>>Wow, all inactive pages moved to active and sit there even after proc= ess > >>>>was terminated, that's not good, what do you think? > >>>Why do you think this is 'not good' ? You have plenty of free memory, > >>>there is no memory pressure, and all pages were referenced recently. > >>>THere is no reason for them to be deactivated. > >>> > >> > >>I always thought that active memory this is a sum of resident memory of > >>all processes, inactive shows disk cache and wired shows kernel itself. > >So you are wrong. Both active and inactive memory can be mapped and > >not mapped, both can belong to vnode or to anonymous objects etc. > >Active/inactive distinction is only the amount of references that was > >noted by pagedaemon, or some other page history like the way it was > >unwired. > > > >Wired is not neccessary means kernel-used pages, user processes can > >wire their pages as well. >=20 > Let's talk about that in details. >=20 > My understanding is the following: >=20 > Active memory: the memory which is referenced by application. An=20 Assuming the part 'by application' is removed, this sentence is almost righ= t. Any managed mapping of the page participates in the active references. > application may get memory only through mmap() (allocator don't use=20 > brk()/sbrk() any more). The resident memory of an application is the=20 > sum of physical used memory. So, sum of RSS is active memory. First, brk/sbrk is still used. Second, there is no requirement that resident pages are referenced. E.g. page could have participated in the buffer, and unwiring on the buffer dissolve put it into inactive state. Or pagedaemon cleared the reference and moved the page to inactive queue. Or the page was prefaulted by different optimizations. More, there is subtle difference between 'resident' and 'not causing fault on access'. Page may be resident, but pte was not preinstalled, or pte was flushed etc. >=20 > Inactive memory: the memory which has no references. Once we call=20 > read() on the file, the file is in inactive memory, because we have no=20 > references to this object, we just read it. This is also released=20 > memory by free(). On buffers dissolve, buffer cache explicitely puts pages constituing=20 the buffer, into the inactive queue. In fact, this is not quite right, e.g. if the same pages are mapped and actively referenced, then pagedaemon has slightly more work now to move the page from inactive to active. And, free(3) operates at so much higher level then vm subsystem that describing the interaction between these two is impossible in any definitive mood. Old naive mallocs put block description at the beggining of the block, actually causing free() to reference at least the first page of the block. Jemalloc often does madvise(MADV_FREE) for large freed allocations. MADV_FREE moves pages between queues probabalistically. >=20 > Cache memory: I don't know what is it. It's always small enough to not=20 > think about it. This was the bug you reported, and which Alan fixed on Sunday. >=20 > Wired memory: kernel memory and yes, application may get wired memory=20 > through mlock()/mlockall(), but I haven't seen any real application=20 > which calls mlock(). ntpd, amd from the base system. gpg and similar programs try to mlock key store to avoid sensitive material leakage to the swap. cdrecord(8) tried to mlock itself to avoid indefinite stalls during write. >=20 > >> > >>>> > >>>>Read the file: > >>>>$ cat /mnt/random> /dev/null > >>>> > >>>>Mem: 79M Active, 55M Inact, 1746M Wired, 1240M Buf, 45G Free > >>>> > >>>>Now the file is in wired memory. I do not understand why so. > >>>You do use UFS, right ? > >> > >>Yes. > >> > >>>There is enough buffer headers and buffer KVA > >>>to have buffers allocated for the whole file content. Since buffers wi= re > >>>corresponding pages, you get pages migrated to wired. > >>> > >>>When there appears a buffer pressure (i.e., any other i/o started), > >>>the buffers will be repurposed and pages moved to inactive. > >>> > >> > >>OK, how can I get amount of disk cache? > >You cannot. At least I am not aware of any counter that keeps track > >of the resident pages belonging to vnode pager. > > > >Buffers should not be thought as disk cache, pages cache disk content. > >Instead, VMIO buffers only provide bread()/bwrite() compatible interface > >to the page cache (*) for filesystems. > >(*) - The cache term is used in generic term, not to confuse with > >cached pages counter from top etc. > > >=20 > Yes, I know that. I try once again to ask my question about buffers.=20 > Is this reasonable to use for them 10% of the physical memory or we may= =20 > set rational upper limit automatically? >=20 > >> > >>>> > >>>>Could you please give me explanation about active/inactive/wired memo= ry? > >>>> > >>>> > >>>>>because I suspect that the current code does more harm than good. In > >>>>>theory, it saves activations of the page daemon. However, more often > >>>>>than not, I suspect that we are spending more on page reactivations= =20 > >>>>>than > >>>>>we are saving on page daemon activations. The sequential access > >>>>>detection heuristic is just too easily triggered. For example, I've= =20 > >>>>>seen > >>>>>it triggered by demand paging of the gcc text segment. Also, I think > >>>>>that pmap_remove_all() and especially vm_page_cache() are too severe= =20 > >>>>>for > >>>>>a detection heuristic that is so easily triggered. > >>>>> > >>>>[snip] > >>>> > >>>>-- > >>>>Andrey Zonov > >> > >>-- > >>Andrey Zonov >=20 > --=20 > Andrey Zonov --Iby4wbbvBBYJWhzT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+CqW8ACgkQC3+MBN1Mb4iBLACdGJuYNxTgkKMk4EDVo6wTnEZX E0kAn3fl7avgZvjOA9F5f3t7xgBri8hk =WFcu -----END PGP SIGNATURE----- --Iby4wbbvBBYJWhzT-- From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 9 11:35:31 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B9C3D106564A for ; Mon, 9 Apr 2012 11:35:31 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 41FF88FC1A for ; Mon, 9 Apr 2012 11:35:31 +0000 (UTC) Received: by wgbds12 with SMTP id ds12so4152478wgb.31 for ; Mon, 09 Apr 2012 04:35:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=YYYIghceHTRlro25UHZveP2p2WfnWbETuM3C5LrfvRw=; b=iCdktrK3f9o70sOR1+YgGVvWnAdL2kPIxVWkALFyh2vsZpebgXpdRyecWJG8LI7TYI 2CTlknk7z5QNWedp9/Cs+7h0EIzJwVa5oKoDn8JqRyJlfnhmBWDDXcl3CZ0K3M6dB7Jg 4TRrEypTneAlOjg9pvGxZLkfVxHNmpWqZhvG1P4fO1E5m+AyHru+pR9ARMW7fenhLkMZ oGWwWXU8wIr1nDpCRhcCoKn7Sc5phpliEul3H7Nhm9I9UhtYjuEeVJJ/KZ0n1lgkhX3u MxohWyK9YYfz/n/zNp6EgS82YTay0TYCDAQBebuyZ2ZxKxskwiOiD/Lt6TESun4swrTt I3PA== MIME-Version: 1.0 Received: by 10.180.104.137 with SMTP id ge9mr15044031wib.20.1333971330264; Mon, 09 Apr 2012 04:35:30 -0700 (PDT) Received: by 10.180.80.230 with HTTP; Mon, 9 Apr 2012 04:35:30 -0700 (PDT) X-Originating-IP: [95.108.170.198] In-Reply-To: <20120409091839.GH2358@deviant.kiev.zoral.com.ua> References: <4F7B495D.3010402@zonov.org> <20120404071746.GJ2358@deviant.kiev.zoral.com.ua> <4F7DC037.9060803@rice.edu> <4F7DF39A.3000500@zonov.org> <20120405194122.GC2358@deviant.kiev.zoral.com.ua> <4F7DF88D.2050907@zonov.org> <20120406081349.GE2358@deviant.kiev.zoral.com.ua> <4F828D15.8080604@zonov.org> <20120409091839.GH2358@deviant.kiev.zoral.com.ua> Date: Mon, 9 Apr 2012 15:35:30 +0400 Message-ID: From: Andrey Zonov To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl7EamPvol5lPTHFM034snuqXpuTPAgWkPkkueZyGc4VlqUSsUEI0xtsaxlT8NN/uMYgYXD Cc: alc@freebsd.org, freebsd-hackers@freebsd.org, Alan Cox Subject: Re: problems with mmap() and disk caching X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 11:35:31 -0000 On Mon, Apr 9, 2012 at 1:18 PM, Konstantin Belousov w= rote: > On Mon, Apr 09, 2012 at 11:17:41AM +0400, Andrey Zonov wrote: >> On 06.04.2012 12:13, Konstantin Belousov wrote: >> >On Thu, Apr 05, 2012 at 11:54:53PM +0400, Andrey Zonov wrote: [snip] >> >>I always thought that active memory this is a sum of resident memory o= f >> >>all processes, inactive shows disk cache and wired shows kernel itself= . >> >So you are wrong. Both active and inactive memory can be mapped and >> >not mapped, both can belong to vnode or to anonymous objects etc. >> >Active/inactive distinction is only the amount of references that was >> >noted by pagedaemon, or some other page history like the way it was >> >unwired. >> > >> >Wired is not neccessary means kernel-used pages, user processes can >> >wire their pages as well. >> >> Let's talk about that in details. >> >> My understanding is the following: >> >> Active memory: the memory which is referenced by application. =A0An > Assuming the part 'by application' is removed, this sentence is almost ri= ght. > Any managed mapping of the page participates in the active references. > >> application may get memory only through mmap() (allocator don't use >> brk()/sbrk() any more). =A0The resident memory of an application is the >> sum of physical used memory. =A0So, sum of RSS is active memory. > First, brk/sbrk is still used. Second, there is no requirement that > resident pages are referenced. E.g. page could have participated in the > buffer, and unwiring on the buffer dissolve put it into inactive state. > Or pagedaemon cleared the reference and moved the page to inactive queue. > Or the page was prefaulted by different optimizations. > > More, there is subtle difference between 'resident' and 'not causing faul= t > on access'. Page may be resident, but pte was not preinstalled, or pte > was flushed etc. >From the user point of view: how can the memory be active if no-one (I mean application) use it? What I really saw not at once is that the program for a long time worked with big mmap()'ed file, couldn't work well (many page faults) with new version of the file, until I manually flushed active memory by FS re-mounting. New version couldn't force out the old one. In my opinion if VM moved cached objects to inactive queue after program termination I wouldn't see this problem. >> >> Inactive memory: the memory which has no references. =A0Once we call >> read() on the file, the file is in inactive memory, because we have no >> references to this object, we just read it. =A0This is also released >> memory by free(). > On buffers dissolve, buffer cache explicitely puts pages constituing > the buffer, into the inactive queue. In fact, this is not quite right, > e.g. if the same pages are mapped and actively referenced, then > pagedaemon has slightly more work now to move the page from inactive > to active. > Yes, sure, if someone else use the object it should be active and even better to introduce new "SHARED" counter, like one is in MacOSX and Linux. > And, free(3) operates at so much higher level then vm subsystem that > describing the interaction between these two is impossible in any > definitive mood. Old naive mallocs put block description at the beggining > of the block, actually causing free() to reference at least the first > page of the block. Jemalloc often does madvise(MADV_FREE) for large > freed allocations. MADV_FREE =A0moves pages between queues probabalistica= lly. > That's exactly what I meant by free(). We drop act_count to 0 and move page to inactive queue by vm_page_dontneed() >> >> Cache memory: I don't know what is it. It's always small enough to not >> think about it. > This was the bug you reported, and which Alan fixed on Sunday. > I've tested this patch under 9.0-STABLE and should say that it introduces problems with interactivity on heavy disk loaded machines. With the patch that I tested before I didn't observe such problems. >> >> Wired memory: kernel memory and yes, application may get wired memory >> through mlock()/mlockall(), but I haven't seen any real application >> which calls mlock(). > ntpd, amd from the base system. gpg and similar programs try to mlock > key store to avoid sensitive material leakage to the swap. cdrecord(8) > tried to mlock itself to avoid indefinite stalls during write. > Nice catch ;-) > >> >> >> >> >>>> >> >>>>Read the file: >> >>>>$ cat /mnt/random> =A0 /dev/null >> >>>> >> >>>>Mem: 79M Active, 55M Inact, 1746M Wired, 1240M Buf, 45G Free >> >>>> >> >>>>Now the file is in wired memory. =A0I do not understand why so. >> >>>You do use UFS, right ? >> >> >> >>Yes. >> >> >> >>>There is enough buffer headers and buffer KVA >> >>>to have buffers allocated for the whole file content. Since buffers w= ire >> >>>corresponding pages, you get pages migrated to wired. >> >>> >> >>>When there appears a buffer pressure (i.e., any other i/o started), >> >>>the buffers will be repurposed and pages moved to inactive. >> >>> >> >> >> >>OK, how can I get amount of disk cache? >> >You cannot. At least I am not aware of any counter that keeps track >> >of the resident pages belonging to vnode pager. >> > >> >Buffers should not be thought as disk cache, pages cache disk content. >> >Instead, VMIO buffers only provide bread()/bwrite() compatible interfac= e >> >to the page cache (*) for filesystems. >> >(*) - The cache term is used in generic term, not to confuse with >> >cached pages counter from top etc. >> > >> >> Yes, I know that. =A0I try once again to ask my question about buffers. >> Is this reasonable to use for them 10% of the physical memory or we may >> set rational upper limit automatically? >> This question is still without answer :) >> >> >> >>>> >> >>>>Could you please give me explanation about active/inactive/wired mem= ory? >> >>>> >> >>>> >> >>>>>because I suspect that the current code does more harm than good. I= n >> >>>>>theory, it saves activations of the page daemon. However, more ofte= n >> >>>>>than not, I suspect that we are spending more on page reactivations >> >>>>>than >> >>>>>we are saving on page daemon activations. The sequential access >> >>>>>detection heuristic is just too easily triggered. For example, I've >> >>>>>seen >> >>>>>it triggered by demand paging of the gcc text segment. Also, I thin= k >> >>>>>that pmap_remove_all() and especially vm_page_cache() are too sever= e >> >>>>>for >> >>>>>a detection heuristic that is so easily triggered. >> >>>>> >> >>>>[snip] >> >>>> >> >>>>-- >> >>>>Andrey Zonov >> >> >> >>-- >> >>Andrey Zonov >> >> -- >> Andrey Zonov --=20 Andrey Zonov From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 9 12:22:45 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8A7A11065670; Mon, 9 Apr 2012 12:22:45 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id BF1268FC0A; Mon, 9 Apr 2012 12:22:44 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q39CMOsa033298; Mon, 9 Apr 2012 15:22:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q39CMO9Y049675; Mon, 9 Apr 2012 15:22:24 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q39CMOFg049674; Mon, 9 Apr 2012 15:22:24 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 9 Apr 2012 15:22:24 +0300 From: Konstantin Belousov To: Andrey Zonov Message-ID: <20120409122224.GN2358@deviant.kiev.zoral.com.ua> References: <4F7B495D.3010402@zonov.org> <20120404071746.GJ2358@deviant.kiev.zoral.com.ua> <4F7DC037.9060803@rice.edu> <4F7DF39A.3000500@zonov.org> <20120405194122.GC2358@deviant.kiev.zoral.com.ua> <4F7DF88D.2050907@zonov.org> <20120406081349.GE2358@deviant.kiev.zoral.com.ua> <4F828D15.8080604@zonov.org> <20120409091839.GH2358@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8ng/5ht+ekz7N9c2" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: alc@freebsd.org, freebsd-hackers@freebsd.org, Alan Cox Subject: Re: problems with mmap() and disk caching X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 12:22:45 -0000 --8ng/5ht+ekz7N9c2 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 09, 2012 at 03:35:30PM +0400, Andrey Zonov wrote: > On Mon, Apr 9, 2012 at 1:18 PM, Konstantin Belousov = wrote: > > On Mon, Apr 09, 2012 at 11:17:41AM +0400, Andrey Zonov wrote: > >> On 06.04.2012 12:13, Konstantin Belousov wrote: > >> >On Thu, Apr 05, 2012 at 11:54:53PM +0400, Andrey Zonov wrote: > [snip] > >> >>I always thought that active memory this is a sum of resident memory= of > >> >>all processes, inactive shows disk cache and wired shows kernel itse= lf. > >> >So you are wrong. Both active and inactive memory can be mapped and > >> >not mapped, both can belong to vnode or to anonymous objects etc. > >> >Active/inactive distinction is only the amount of references that was > >> >noted by pagedaemon, or some other page history like the way it was > >> >unwired. > >> > > >> >Wired is not neccessary means kernel-used pages, user processes can > >> >wire their pages as well. > >> > >> Let's talk about that in details. > >> > >> My understanding is the following: > >> > >> Active memory: the memory which is referenced by application. =9AAn > > Assuming the part 'by application' is removed, this sentence is almost = right. > > Any managed mapping of the page participates in the active references. > > > >> application may get memory only through mmap() (allocator don't use > >> brk()/sbrk() any more). =9AThe resident memory of an application is the > >> sum of physical used memory. =9ASo, sum of RSS is active memory. > > First, brk/sbrk is still used. Second, there is no requirement that > > resident pages are referenced. E.g. page could have participated in the > > buffer, and unwiring on the buffer dissolve put it into inactive state. > > Or pagedaemon cleared the reference and moved the page to inactive queu= e. > > Or the page was prefaulted by different optimizations. > > > > More, there is subtle difference between 'resident' and 'not causing fa= ult > > on access'. Page may be resident, but pte was not preinstalled, or pte > > was flushed etc. >=20 > >From the user point of view: how can the memory be active if no-one (I > mean application) use it? >=20 > What I really saw not at once is that the program for a long time > worked with big mmap()'ed file, couldn't work well (many page faults) > with new version of the file, until I manually flushed active memory > by FS re-mounting. New version couldn't force out the old one. In my > opinion if VM moved cached objects to inactive queue after program > termination I wouldn't see this problem. Moving pages to inactive just because some mapping was destroyed is plain silly. The pages migrate between active/inactive/cache/free by the pagedaemon algorithms. BTW, you do not need to actually remount filesystem to flush pages of its vnodes. It is enough to try to unmount it while cd to filesystem root. >=20 > >> > >> Inactive memory: the memory which has no references. =9AOnce we call > >> read() on the file, the file is in inactive memory, because we have no > >> references to this object, we just read it. =9AThis is also released > >> memory by free(). > > On buffers dissolve, buffer cache explicitely puts pages constituing > > the buffer, into the inactive queue. In fact, this is not quite right, > > e.g. if the same pages are mapped and actively referenced, then > > pagedaemon has slightly more work now to move the page from inactive > > to active. > > >=20 > Yes, sure, if someone else use the object it should be active and even > better to introduce new "SHARED" counter, like one is in MacOSX and > Linux. Counter for what ? There is already the ref counter for a vm object. >=20 > > And, free(3) operates at so much higher level then vm subsystem that > > describing the interaction between these two is impossible in any > > definitive mood. Old naive mallocs put block description at the beggini= ng > > of the block, actually causing free() to reference at least the first > > page of the block. Jemalloc often does madvise(MADV_FREE) for large > > freed allocations. MADV_FREE =9Amoves pages between queues probabalisti= cally. > > >=20 > That's exactly what I meant by free(). We drop act_count to 0 and > move page to inactive queue by vm_page_dontneed() >=20 > >> > >> Cache memory: I don't know what is it. It's always small enough to not > >> think about it. > > This was the bug you reported, and which Alan fixed on Sunday. > > >=20 > I've tested this patch under 9.0-STABLE and should say that it > introduces problems with interactivity on heavy disk loaded machines. > With the patch that I tested before I didn't observe such problems. >=20 > >> > >> Wired memory: kernel memory and yes, application may get wired memory > >> through mlock()/mlockall(), but I haven't seen any real application > >> which calls mlock(). > > ntpd, amd from the base system. gpg and similar programs try to mlock > > key store to avoid sensitive material leakage to the swap. cdrecord(8) > > tried to mlock itself to avoid indefinite stalls during write. > > >=20 > Nice catch ;-) >=20 > > > >> > >> >> > >> >>>> > >> >>>>Read the file: > >> >>>>$ cat /mnt/random> =9A /dev/null > >> >>>> > >> >>>>Mem: 79M Active, 55M Inact, 1746M Wired, 1240M Buf, 45G Free > >> >>>> > >> >>>>Now the file is in wired memory. =9AI do not understand why so. > >> >>>You do use UFS, right ? > >> >> > >> >>Yes. > >> >> > >> >>>There is enough buffer headers and buffer KVA > >> >>>to have buffers allocated for the whole file content. Since buffers= wire > >> >>>corresponding pages, you get pages migrated to wired. > >> >>> > >> >>>When there appears a buffer pressure (i.e., any other i/o started), > >> >>>the buffers will be repurposed and pages moved to inactive. > >> >>> > >> >> > >> >>OK, how can I get amount of disk cache? > >> >You cannot. At least I am not aware of any counter that keeps track > >> >of the resident pages belonging to vnode pager. > >> > > >> >Buffers should not be thought as disk cache, pages cache disk content. > >> >Instead, VMIO buffers only provide bread()/bwrite() compatible interf= ace > >> >to the page cache (*) for filesystems. > >> >(*) - The cache term is used in generic term, not to confuse with > >> >cached pages counter from top etc. > >> > > >> > >> Yes, I know that. =9AI try once again to ask my question about buffers. > >> Is this reasonable to use for them 10% of the physical memory or we may > >> set rational upper limit automatically? > >> >=20 > This question is still without answer :) What is the rational upper limit ? Buffers do not consume separate physical memory, the amount of memory reported as used by buffers is KVA. Mostly, amount of buffer space limits the amount of outstanding i/o, including delayed write requests. Buffers maps the cached vnode pages into kernel address space for filesystems. >=20 > >> >> > >> >>>> > >> >>>>Could you please give me explanation about active/inactive/wired m= emory? > >> >>>> > >> >>>> > >> >>>>>because I suspect that the current code does more harm than good.= In > >> >>>>>theory, it saves activations of the page daemon. However, more of= ten > >> >>>>>than not, I suspect that we are spending more on page reactivatio= ns > >> >>>>>than > >> >>>>>we are saving on page daemon activations. The sequential access > >> >>>>>detection heuristic is just too easily triggered. For example, I'= ve > >> >>>>>seen > >> >>>>>it triggered by demand paging of the gcc text segment. Also, I th= ink > >> >>>>>that pmap_remove_all() and especially vm_page_cache() are too sev= ere > >> >>>>>for > >> >>>>>a detection heuristic that is so easily triggered. > >> >>>>> > >> >>>>[snip] > >> >>>> > >> >>>>-- > >> >>>>Andrey Zonov > >> >> > >> >>-- > >> >>Andrey Zonov > >> > >> -- > >> Andrey Zonov >=20 >=20 >=20 > --=20 > Andrey Zonov --8ng/5ht+ekz7N9c2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+C1H8ACgkQC3+MBN1Mb4iYdwCdGv91bxbVBzIRmN8YPX1VNLji zmgAoMgHknz0KMLNIfsvwSa4cayOdCN9 =ye/o -----END PGP SIGNATURE----- --8ng/5ht+ekz7N9c2-- From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 9 14:49:45 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A36271065670 for ; Mon, 9 Apr 2012 14:49:45 +0000 (UTC) (envelope-from bfalk_bsd@brandonfa.lk) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4B4968FC16 for ; Mon, 9 Apr 2012 14:49:45 +0000 (UTC) Received: by yenl9 with SMTP id l9so2229551yen.13 for ; Mon, 09 Apr 2012 07:49:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brandonfa.lk; s=google; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ixK5Oof/s8tF1bTBi69L9WK3mI2mOL3Yp1gxkccZvT4=; b=L6c0Io5xtiHZ+FgpYd7qODy0r5U1DUGE7di6x4e7MVNBdYfxI1hHHvsYwuuvtN1Pp0 vbBM1NYyj2N2PIjoBclxLnKMLEczHQWftJvNxjNv2pHFi/xJavVAg2NzxTNHNU+xZDta xw3KQGoCiAFaI/088tsRa52Rn+TaxCSFKkEAM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=ixK5Oof/s8tF1bTBi69L9WK3mI2mOL3Yp1gxkccZvT4=; b=BlDWabjpA9Fax9gfzzh5ZeLRMYD4hsuBpLcIHCp+b3llF54it5UKbq7Ylp3k/Dhjt8 ew2cL1s5zqZbNAxbvw8q0IfXr/Wfv/oPL45IcMNMYwqCwusTUL14/IKzNKyYGQJTkZhR s5uB4dowZKw6C+BZLED77xeipq1EPLj5h9qh/8AafFj4yMq9lRVegZEnABJsNWkVP0cp DahXHJqZvIMZPKNYYuYPr0CqgyplmkPguCUtxHD9MseE4x9IzLRh/y4+BEpfsWPlVA5i 6ZfgV74hqqILP0wPviBIUtiMdzp1XttvN61HWD7e2WrO4YxCiTHBLOnRYgso1BSbKQVC ySpw== Received: by 10.60.0.135 with SMTP id 7mr10731206oee.25.1333982984401; Mon, 09 Apr 2012 07:49:44 -0700 (PDT) Received: from [192.168.42.108] (wsip-184-183-177-134.dc.dc.cox.net. [184.183.177.134]) by mx.google.com with ESMTPS id o6sm12811315oec.11.2012.04.09.07.49.42 (version=SSLv3 cipher=OTHER); Mon, 09 Apr 2012 07:49:42 -0700 (PDT) Message-ID: <4F82F705.304@brandonfa.lk> Date: Mon, 09 Apr 2012 10:49:41 -0400 From: Brandon Falk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Michael Cardell Widerkrantz References: <4F55A0EA.8000300@gmail.com> <4f5635d4.5Qp6ViEgiFLUuPKI%perryh@pluto.rain.com> <86ipha2eiy.fsf@totoro.hack.org> In-Reply-To: <86ipha2eiy.fsf@totoro.hack.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmCMZrn+eYz9IEFFTyxhYk2vU0xUpC5iOuK9s4yporLuyBsWJXjus8CVweZH4LqjP2Ys+QI Cc: freebsd-hackers@freebsd.org Subject: Re: Graphical Terminal Environment X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 14:49:45 -0000 I'm still avidly trying to work on this idea, but right now the issue seems to be with AMD and NVIDIA not documenting their protocols. Intel does a good job, but I don't have any Intel chips with graphics laying around. Right now I've targeted what I think is the main issue, and that is the closed-protocol GPU. I'm working on a minimal GPU right now on an FPGA. Not sure if it will actually end up going anywhere, but I would really like to see an open-hardware GPU out on the market. Certainly it would not be an NVIDIA or AMD killer, but it would be a good card for people who just want to watch videos, browse the web, run terminals, etc. The main focus of this GPU would be to maximize resolutions and monitors, and minimize cost. Currently it looks like I could run 4 monitors at 1080p for about $50 (that's not taking into account bulk-order costs). I could try to work with nouveau (as I did before) but I'll just never feel ok with using a system that uses 'blobs' (nouveau terms for the bits that are sent to the card without knowing what they really are). -Brandon On 4/8/2012 3:45 PM, Michael Cardell Widerkrantz wrote: > Since Brandon started this in a sort of rambling mood I'm keeping up > with the tradition... This is just what's on top of my mind right now. > > perryh@pluto.rain.com, 2012-03-06 17:05 (+0100): > >> I _think_ SunTools/SunView were proprietary, > Absolutely. > >> although it's possible that Sun released the source code at some >> point. > Much of the actual window system in SunView was implemented in the > kernel, IIRC. That might not be interesting in this case. > > Another system I used on quite memory-starved Sun 3/50s (as little as 4 > meg) and 3/60s and later on SPARCstations, was the Bellcore MGR window > system: > > http://hack.org/mc/mgr/ > > http://en.wikipedia.org/wiki/ManaGeR > > Many users in the Lysator academic computing society where I first met > MGR preferred it to SunView. It was really nice on monochrome monitors > at 1152x900. It's also network transparent so you can run remote > graphics applications. > > MGR was ported to a lot of systems, including FreeBSD. It might still > compile, but it's unlikely to support anything higher than 640x480 on > FreeBSD. If anyone tries to compile it and runs into problems I might be > able to help. Just e-mail me. > > To support higher resolutions on FreeBSD Brandon would have to rewrite > the functions in libbitblit. One way to do it would be to use vgl(3) to > implement the libbitblit functions. Should be pretty straightforward, I > think, and not too much work. > > On the other hand vgl(3) probably only supports VESA so Brandon will > still have to write a special libbitblit for the nvidia card he > mentions. > > MGR doesn't tile windows but Brandon might want to add a mode to do > that. > > MGR has a slightly bothersome license, though, forbidding commercial > sales so this might not be the best way forward. > > On Sun SPARCs under SunOS it was also possible to run a tiling window > system called Oberon. It shares its name with a programming language and > a complete native operating system. Oberon is a complete environment > using the Oberon programming language so it might not be what Brandon > wants but it might be interesting to look at nonetheless. > > I believe Oberon is still available and can run either as a native > operating system or as an environment under other systems. The SPARC > port I used many years ago was running under SunOS but was running > directly on the console. I don't know if there are any modern Oberon > systems that can do that. > > Incidentally, Oberon was one of the inspirations behind Rob Pike's acme > editor on Plan 9. Acme, however, just handles text. Oberon does graphics > as well. > > I've been thinking something along the same lines as Brandon for several > years now: to write a lightweight window system. For many years I > resisted X and kept using MGR, even going so far as porting MGR to > Solaris and to Linux/SPARC just to be able to keep using MGR on more > modern systems. I gave up, I think, around 1994. > > If I would do it again I would probably not work on MGR but I might use > it for some ideas. One thing that MGR does that I wouldn't do was to > force all graphics operations to be done through escape codes in > terminal windows. While it might be great for network transparance it's > not so great for the speed of local programs. > > The Wayland project is interesting but seems very Linux oriented. On the > other hand work on KMS/GEM support on FreeBSD is coming along. It might > be possible to get Wayland running on FreeBSD. I haven't looked into it > myself (yet). > > James Gosling, who wrote both the Andrew window system and Sun's NeWS > (not SunView, the *other* Sun window system, the one with a Postscript > interpreter) has written an interesting paper about window system > design. I have a copy here: > > http://hack.org/mc/texts/gosling-wsd.pdf > > Some people have mentioned Plan 9's 8 1/2 and rio. They are both very > interesting window systems. While I think they have a very clean design > I think they might be problematic to implement in a system other than > Plan 9. > > You see, both 8 1/2 and rio are *file servers*. They make heavy use of > the fact that the namespace of files in Plan 9 is local to processes. > Reading from /dev/mouse from a process under 8 1/2, for instance, means > listening to mouse events in the window that process is running in. > Another process has a *completely separate* /dev/mouse file but is using > *the same name*. Neat, but not very portable. > > I've used 8 1/2 many years ago but haven't used rio. I believe the > difference between them is fairly small, but I might be wrong: I think > rio allows the process to write pixels directly to a window while 8 1/2 > uses special commands written to /dev/bitblt. Right? > > Rob Pike, the author of both 8 1/2 and rio, also wrote several earlier > window systems that are interesting, for intance mtx and mux on the Blit > and its decendants, the AT&T Teletype 5620 DMD, AT&T 630 and 730. Some > software for these terminals/light workstations is still available. See: > > http://www.brouhaha.com/~eric/retrocomputing/att/5620/ > > An entertainging video featuring Pike and the Blit is available here: > > http://www.youtube.com/watch?v=waTL1abCm9I > > Notice that they really felt the need to explain how a mouse works. > Alright, this was 1982. > > An interesting idea I've been thinking about is making a new window > system API at least partially compatible with either MGR's API (not the > escape codes - the C functions) or the AT&T terminal's API, or perhaps > making a compatibility library. This way a lot of fairly nice very > lightweight software like troff previewers et cetera would be available > from the start. > > Is this a waste of time? I don't know. For instance X11 on the grownup > smartphone I use right now, an ARM based netbook from Genesi, is nice to > have but there's very limited memory on the box and I would rather use > the memory for something else. One of my thin clients, an HP t5125 from > 2005, has even less memory: 128 MiB soldered on the motherboard. It > still makes a quite nice diskless workstation but with a more > lightweight window system it would be nicer still. I think there are > many such boxen around that might still be useful. > > Happy hacking, > MC > From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 9 15:36:47 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C97881065670 for ; Mon, 9 Apr 2012 15:36:47 +0000 (UTC) (envelope-from feld@feld.me) Received: from feld.me (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id 915D28FC08 for ; Mon, 9 Apr 2012 15:36:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=In-Reply-To:Message-Id:From:Mime-Version:Date:References:Subject:To:Content-Type; bh=WK9uJm463dQUForLm9uV89xEkajvWPPbT+EeDkdtQug=; b=r5s3k/nxtTQ+JToq3b4hwIXMoJvQMCmUZn1vUDpVkxc4PDmCngEmg6ATQ03uOqv3jvU8kaN/+AajCcXLSaLoCSxzi+1FpNxvIgcOdQpMbnVvVuT/XGrixI+AB3rit/GM; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by feld.me with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SHGe1-0001h8-9U for freebsd-hackers@freebsd.org; Mon, 09 Apr 2012 10:36:47 -0500 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpa id 1333985794-23734-23733/5/3; Mon, 9 Apr 2012 15:36:34 +0000 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-hackers@freebsd.org References: Date: Mon, 9 Apr 2012 10:36:34 -0500 Mime-Version: 1.0 From: Mark Felder Message-Id: In-Reply-To: User-Agent: Opera Mail/11.62 (FreeBSD) X-SA-Score: -1.5 Subject: Re: time stops in vmware X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 15:36:47 -0000 On Sun, 08 Apr 2012 02:11:25 -0500, Daniel Braniss wrote: > Hi All > There was some mention before that time stops under vmware, and now it's > happened > to me :-) > > the clock stopped now, the system is responsive, but eg > sleep 1 > never finishes. > Is there a solution? > btw, I'm running 8.2-stable, i'll try 8.3 soon. > Can you recreate it? Does it go away if you use "kern.hz=200" in loader.conf? We used to have to do that. From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 9 16:34:45 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C957106566B; Mon, 9 Apr 2012 16:34:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4540C8FC14; Mon, 9 Apr 2012 16:34:45 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A7BD7B979; Mon, 9 Apr 2012 12:34:44 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 9 Apr 2012 11:26:25 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <4F7B495D.3010402@zonov.org> <20120404071746.GJ2358@deviant.kiev.zoral.com.ua> <4F7DC037.9060803@rice.edu> In-Reply-To: <4F7DC037.9060803@rice.edu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201204091126.25260.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 09 Apr 2012 12:34:44 -0400 (EDT) Cc: Konstantin Belousov , alc@freebsd.org, Andrey Zonov , Alan Cox Subject: Re: problems with mmap() and disk caching X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 16:34:45 -0000 On Thursday, April 05, 2012 11:54:31 am Alan Cox wrote: > On 04/04/2012 02:17, Konstantin Belousov wrote: > > On Tue, Apr 03, 2012 at 11:02:53PM +0400, Andrey Zonov wrote: > >> Hi, > >> > >> I open the file, then call mmap() on the whole file and get pointer, > >> then I work with this pointer. I expect that page should be only once > >> touched to get it into the memory (disk cache?), but this doesn't work! > >> > >> I wrote the test (attached) and ran it for the 1G file generated from > >> /dev/random, the result is the following: > >> > >> Prepare file: > >> # swapoff -a > >> # newfs /dev/ada0b > >> # mount /dev/ada0b /mnt > >> # dd if=/dev/random of=/mnt/random-1024 bs=1m count=1024 > >> > >> Purge cache: > >> # umount /mnt > >> # mount /dev/ada0b /mnt > >> > >> Run test: > >> $ ./mmap /mnt/random-1024 30 > >> mmap: 1 pass took: 7.431046 (none: 262112; res: 32; super: > >> 0; other: 0) > >> mmap: 2 pass took: 7.356670 (none: 261648; res: 496; super: > >> 0; other: 0) > >> mmap: 3 pass took: 7.307094 (none: 260521; res: 1623; super: > >> 0; other: 0) > >> mmap: 4 pass took: 7.350239 (none: 258904; res: 3240; super: > >> 0; other: 0) > >> mmap: 5 pass took: 7.392480 (none: 257286; res: 4858; super: > >> 0; other: 0) > >> mmap: 6 pass took: 7.292069 (none: 255584; res: 6560; super: > >> 0; other: 0) > >> mmap: 7 pass took: 7.048980 (none: 251142; res: 11002; super: > >> 0; other: 0) > >> mmap: 8 pass took: 6.899387 (none: 247584; res: 14560; super: > >> 0; other: 0) > >> mmap: 9 pass took: 7.190579 (none: 242992; res: 19152; super: > >> 0; other: 0) > >> mmap: 10 pass took: 6.915482 (none: 239308; res: 22836; super: > >> 0; other: 0) > >> mmap: 11 pass took: 6.565909 (none: 232835; res: 29309; super: > >> 0; other: 0) > >> mmap: 12 pass took: 6.423945 (none: 226160; res: 35984; super: > >> 0; other: 0) > >> mmap: 13 pass took: 6.315385 (none: 208555; res: 53589; super: > >> 0; other: 0) > >> mmap: 14 pass took: 6.760780 (none: 192805; res: 69339; super: > >> 0; other: 0) > >> mmap: 15 pass took: 5.721513 (none: 174497; res: 87647; super: > >> 0; other: 0) > >> mmap: 16 pass took: 5.004424 (none: 155938; res: 106206; super: > >> 0; other: 0) > >> mmap: 17 pass took: 4.224926 (none: 135639; res: 126505; super: > >> 0; other: 0) > >> mmap: 18 pass took: 3.749608 (none: 117952; res: 144192; super: > >> 0; other: 0) > >> mmap: 19 pass took: 3.398084 (none: 99066; res: 163078; super: > >> 0; other: 0) > >> mmap: 20 pass took: 3.029557 (none: 74994; res: 187150; super: > >> 0; other: 0) > >> mmap: 21 pass took: 2.379430 (none: 55231; res: 206913; super: > >> 0; other: 0) > >> mmap: 22 pass took: 2.046521 (none: 40786; res: 221358; super: > >> 0; other: 0) > >> mmap: 23 pass took: 1.152797 (none: 30311; res: 231833; super: > >> 0; other: 0) > >> mmap: 24 pass took: 0.972617 (none: 16196; res: 245948; super: > >> 0; other: 0) > >> mmap: 25 pass took: 0.577515 (none: 8286; res: 253858; super: > >> 0; other: 0) > >> mmap: 26 pass took: 0.380738 (none: 3712; res: 258432; super: > >> 0; other: 0) > >> mmap: 27 pass took: 0.253583 (none: 1193; res: 260951; super: > >> 0; other: 0) > >> mmap: 28 pass took: 0.157508 (none: 0; res: 262144; super: > >> 0; other: 0) > >> mmap: 29 pass took: 0.156169 (none: 0; res: 262144; super: > >> 0; other: 0) > >> mmap: 30 pass took: 0.156550 (none: 0; res: 262144; super: > >> 0; other: 0) > >> > >> If I ran this: > >> $ cat /mnt/random-1024> /dev/null > >> before test, when result is the following: > >> > >> $ ./mmap /mnt/random-1024 5 > >> mmap: 1 pass took: 0.337657 (none: 0; res: 262144; super: > >> 0; other: 0) > >> mmap: 2 pass took: 0.186137 (none: 0; res: 262144; super: > >> 0; other: 0) > >> mmap: 3 pass took: 0.186132 (none: 0; res: 262144; super: > >> 0; other: 0) > >> mmap: 4 pass took: 0.186535 (none: 0; res: 262144; super: > >> 0; other: 0) > >> mmap: 5 pass took: 0.190353 (none: 0; res: 262144; super: > >> 0; other: 0) > >> > >> This is what I expect. But why this doesn't work without reading file > >> manually? > > Issue seems to be in some change of the behaviour of the reserv or > > phys allocator. I Cc:ed Alan. > > I'm pretty sure that the behavior here hasn't significantly changed in > about twelve years. Otherwise, I agree with your analysis. > > On more than one occasion, I've been tempted to change: > > pmap_remove_all(mt); > if (mt->dirty != 0) > vm_page_deactivate(mt); > else > vm_page_cache(mt); > > to: > > vm_page_dontneed(mt); > > because I suspect that the current code does more harm than good. In > theory, it saves activations of the page daemon. However, more often > than not, I suspect that we are spending more on page reactivations than > we are saving on page daemon activations. The sequential access > detection heuristic is just too easily triggered. For example, I've > seen it triggered by demand paging of the gcc text segment. Also, I > think that pmap_remove_all() and especially vm_page_cache() are too > severe for a detection heuristic that is so easily triggered. Are you planning to commit this? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 9 16:34:51 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 10277106566B for ; Mon, 9 Apr 2012 16:34:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id DAFCD8FC1B for ; Mon, 9 Apr 2012 16:34:50 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 35F3DB9BB; Mon, 9 Apr 2012 12:34:50 -0400 (EDT) From: John Baldwin To: Sushanth Rai Date: Mon, 9 Apr 2012 12:17:05 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <1333674504.97862.YahooMailClassic@web180016.mail.gq1.yahoo.com> In-Reply-To: <1333674504.97862.YahooMailClassic@web180016.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201204091217.05561.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 09 Apr 2012 12:34:50 -0400 (EDT) Cc: freebsd-hackers@freebsd.org Subject: Re: Startvation of realtime piority threads X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 16:34:51 -0000 On Thursday, April 05, 2012 9:08:24 pm Sushanth Rai wrote: > I understand the downside of badly written realtime app. In my case application runs in userspace without making much syscalls and by all means it is a well behaved application. Yes, I can wire memory, change the application to use mutex instead of spinlock and those changes should help but they are still working around the problem. I still believe kernel should not lower the realtime priority when blocking on resources. This can lead to priority inversion, especially since these threads run at fixed priorities and kernel doesn't muck with them. > > As you suggested _sleep() should not adjust the priorities for realtime threads. Hmm, sched_sleep() for both SCHED_4BSD and SCHED_ULE already does the right thing here in HEAD. if (PRI_BASE(td->td_pri_class) != PRI_TIMESHARE) return; Which OS version did you see this on? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 9 18:09:58 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 377A6106564A for ; Mon, 9 Apr 2012 18:09:58 +0000 (UTC) (envelope-from sushanth_rai@yahoo.com) Received: from nm23.bullet.mail.sp2.yahoo.com (nm23.bullet.mail.sp2.yahoo.com [98.139.91.93]) by mx1.freebsd.org (Postfix) with SMTP id 0CE908FC12 for ; Mon, 9 Apr 2012 18:09:58 +0000 (UTC) Received: from [98.139.91.67] by nm23.bullet.mail.sp2.yahoo.com with NNFMP; 09 Apr 2012 18:09:52 -0000 Received: from [98.139.44.77] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 09 Apr 2012 18:08:52 -0000 Received: from [127.0.0.1] by omp1014.access.mail.sp2.yahoo.com with NNFMP; 09 Apr 2012 18:08:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 556930.89548.bm@omp1014.access.mail.sp2.yahoo.com Received: (qmail 58537 invoked by uid 60001); 9 Apr 2012 18:08:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1333994931; bh=tVoQAT/owrGIhU3dC27Aa3jwTXsr1nTDwGOLnlZ/wsE=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Op4btWinCyBdIWT0/KQWNmWDJShn99V4mXOkO3qf0swqfPCDzPzsvaE7QZXFLlgYyHcg4wPTNhnNfY1MsspSHKzZ0tf5jbKVH1Ps15CmjqS4pkj6HtXEADrGwSxyIguJk9k5JjXgTXSBP1pVtVh6AhSVEsjSSkRJhtPPlxAu/EQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=xdLjptPGyBplhq8UHDtibTmlIQ7hbHEFlVXGS0j6S1GkBMc/78lLyR2Yfisv0pK7wz7FsnxLp7kVufy97PNjvI1fwmZ7r2iLiMqRuYCmEl/2xieMAS9GgCu1S0uQoQ21JvPdJ+iiAmsXpSPTCtIwBXAnutUgxEIMW4L+T9pmK7U=; X-YMail-OSG: eZdLQ0cVM1l.ct8gr1BwKi1Vs5fyf_D3fKmywGm3P_a5B3O 7qfxAsq4w2DjxzEpzSK4HnyWDjqO49R7zZUCxO0bOLr9NuMFR6Pt7aWvEak4 TfTNZcDM2XqDYQqYpU.VTPqKkeNpblG53PtGSVFkt3YR7U9KYoU6yjMsUy.6 3HHs4D4Vw9Ji__SJ5TFY3L8BcZN0kAI3XNS9cW33GadE15Mw7LjaqZoH6zND e2q3O9Nj4hzfm3gTc2xCPVmdPHVkqhXmHRzPBJvdFhtIcXSxwH_s6gQe3OSi dvtzzkc5xAz7Aspa8DllTWqcgzThF1svC4uByKlVP7TuJ_Us0HGkNs80Yu_K cN3vxfNOGeHGOGG89Zxq2DS0rNPXqictz1WTxjVIzPUcORoy8_29mPGFhz8q WvH9CWdB3sjXUeMjNZY4H92_tIl6QkUgYQomcRTeCOJklVQM.YFhzZSDHDdk L88bph4w- Received: from [209.119.38.67] by web180004.mail.gq1.yahoo.com via HTTP; Mon, 09 Apr 2012 11:08:50 PDT X-Mailer: YahooMailClassic/15.0.5 YahooMailWebService/0.8.117.340979 Message-ID: <1333994930.58509.YahooMailClassic@web180004.mail.gq1.yahoo.com> Date: Mon, 9 Apr 2012 11:08:50 -0700 (PDT) From: Sushanth Rai To: John Baldwin In-Reply-To: <201204091217.05561.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Startvation of realtime piority threads X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 18:09:58 -0000 I'm on 7.2. sched_sleep() on 7.2 just records the sleep time. That's why I = though _sleep might the right place to do the check.=0A=0AThanks,=0ASushant= h=0A=0A--- On Mon, 4/9/12, John Baldwin wrote:=0A=0A> Fro= m: John Baldwin =0A> Subject: Re: Startvation of realtime = piority threads=0A> To: "Sushanth Rai" =0A> Cc: fre= ebsd-hackers@freebsd.org=0A> Date: Monday, April 9, 2012, 9:17 AM=0A> On Th= ursday, April 05, 2012 9:08:24=0A> pm Sushanth Rai wrote:=0A> > I understan= d the downside of badly written realtime=0A> app.=A0 In my case =0A> applic= ation runs in userspace without making much syscalls=0A> and by all means i= t =0A> is a well behaved application. Yes, I can wire memory,=0A> change th= e application =0A> to use mutex instead of spinlock and those changes shoul= d=0A> help but they are =0A> still working around the problem. I still beli= eve kernel=0A> should not lower the =0A> realtime priority when blocking on= resources. This can lead=0A> to priority =0A> inversion, especially since = these threads run at fixed=0A> priorities and kernel =0A> doesn't muck with= them.=0A> >=A0 =0A> > As you suggested _sleep() should not adjust the=0A> = priorities for realtime =0A> threads. =0A> =0A> Hmm, sched_sleep() for both= SCHED_4BSD and SCHED_ULE already=0A> does the right=0A> thing here in HEAD= .=0A> =0A> =A0=A0=A0 if (PRI_BASE(td->td_pri_class) !=3D=0A> PRI_TIMESHARE)= =0A> =A0=A0=A0 =A0=A0=A0 return;=0A> =0A> Which OS version did you see this= on?=0A> =0A> -- =0A> John Baldwin=0A> From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 9 18:38:11 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E701106566B for ; Mon, 9 Apr 2012 18:38:11 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 050108FC26 for ; Mon, 9 Apr 2012 18:38:11 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6A77CB94F; Mon, 9 Apr 2012 14:38:10 -0400 (EDT) From: John Baldwin To: Sushanth Rai Date: Mon, 9 Apr 2012 14:37:52 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <1333994930.58509.YahooMailClassic@web180004.mail.gq1.yahoo.com> In-Reply-To: <1333994930.58509.YahooMailClassic@web180004.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201204091437.55505.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 09 Apr 2012 14:38:10 -0400 (EDT) Cc: freebsd-hackers@freebsd.org Subject: Re: Startvation of realtime piority threads X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 18:38:11 -0000 On Monday, April 09, 2012 2:08:50 pm Sushanth Rai wrote: > I'm on 7.2. sched_sleep() on 7.2 just records the sleep time. That's why I though _sleep might the right place to do the check. Nah, sched_sleep() is more accurate since the sleep priority can have other side effects. Hmm, in stock 7.2, the rtprio range is below things like PVM, etc., so that shouldn't actually be buggy in that regard. I fixed this in 9.0 and HEAD when I moved the rtprio range up above the kernel sleep priorities. Are you using local patches to 7.2 to raise the priority of rtprio threads? > Thanks, > Sushanth > > --- On Mon, 4/9/12, John Baldwin wrote: > > > From: John Baldwin > > Subject: Re: Startvation of realtime piority threads > > To: "Sushanth Rai" > > Cc: freebsd-hackers@freebsd.org > > Date: Monday, April 9, 2012, 9:17 AM > > On Thursday, April 05, 2012 9:08:24 > > pm Sushanth Rai wrote: > > > I understand the downside of badly written realtime > > app. In my case > > application runs in userspace without making much syscalls > > and by all means it > > is a well behaved application. Yes, I can wire memory, > > change the application > > to use mutex instead of spinlock and those changes should > > help but they are > > still working around the problem. I still believe kernel > > should not lower the > > realtime priority when blocking on resources. This can lead > > to priority > > inversion, especially since these threads run at fixed > > priorities and kernel > > doesn't muck with them. > > > > > > As you suggested _sleep() should not adjust the > > priorities for realtime > > threads. > > > > Hmm, sched_sleep() for both SCHED_4BSD and SCHED_ULE already > > does the right > > thing here in HEAD. > > > > if (PRI_BASE(td->td_pri_class) != > > PRI_TIMESHARE) > > return; > > > > Which OS version did you see this on? > > > > -- > > John Baldwin > > > -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 9 19:57:55 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 558E2106564A; Mon, 9 Apr 2012 19:57:55 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 4DF9D8FC1A; Mon, 9 Apr 2012 19:57:54 +0000 (UTC) Received: by wibhq7 with SMTP id hq7so2376372wib.13 for ; Mon, 09 Apr 2012 12:57:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=+IC9CNuGZVF2mumVmoZ1bSYKcoJNFcVTU4eVVZXzD5o=; b=kvryoOnAepCtahugH1FM/pLQ2jOnWfgEcumc+bSSIM6fk5cPOyLI5u8NvfomJNInZ8 T7D9PT/WteQkb7STKQoqO3OzVV06c8ynSBEm5GcxEdLQ/a2cK6rACaptv6zlWDPrJSgm E40i375AgDICu9jhDhhxZMZYqrE0n8K3VFjLJBHuHFJp0SgxZ3kK6ER9Di2EXnligbiI 5dHACBxAQiO+6oDbx8nMzfAz9XGzxULGHXUIsHenGACR+j+iUA2YLpw0kNStgTlzn3Fr j792cqmCH3tLCDlau+v0/O3DUOc6hR6N7458vx8R6V2maR6PMRfQabrokySEnT0M207S K9jQ== Received: by 10.180.92.228 with SMTP id cp4mr694239wib.2.1334001472964; Mon, 09 Apr 2012 12:57:52 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id h8sm52635643wix.4.2012.04.09.12.57.50 (version=SSLv3 cipher=OTHER); Mon, 09 Apr 2012 12:57:51 -0700 (PDT) Sender: Alexander Motin Message-ID: <4F833F3D.7070106@FreeBSD.org> Date: Mon, 09 Apr 2012 22:57:49 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120226 Thunderbird/10.0.2 MIME-Version: 1.0 To: Arnaud Lacombe References: <4F2F7B7F.40508@FreeBSD.org> <4F366E8F.9060207@FreeBSD.org> <4F367965.6000602@FreeBSD.org> <4F396B24.5090602@FreeBSD.org> <4F3978BC.6090608@FreeBSD.org> <4F3990EA.1080002@FreeBSD.org> <4F3C0BB9.6050101@FreeBSD.org> <4F3E807A.60103@FreeBSD.org> <4F3E8858.4000001@FreeBSD.org> <4F7DE863.6080607@FreeBSD.org> In-Reply-To: <4F7DE863.6080607@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Florian Smeets , Jeff Roberson , Andriy Gapon , FreeBSD current Subject: Re: [RFT][patch] Scheduling for HTT and not only X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 19:57:55 -0000 On 04/05/12 21:45, Alexander Motin wrote: > On 05.04.2012 21:12, Arnaud Lacombe wrote: >> Hi, >> >> [Sorry for the delay, I got a bit sidetrack'ed...] >> >> 2012/2/17 Alexander Motin: >>> On 17.02.2012 18:53, Arnaud Lacombe wrote: >>>> >>>> On Fri, Feb 17, 2012 at 11:29 AM, Alexander Motin >>>> wrote: >>>>> >>>>> On 02/15/12 21:54, Jeff Roberson wrote: >>>>>> >>>>>> On Wed, 15 Feb 2012, Alexander Motin wrote: >>>>>>> >>>>>>> I've decided to stop those cache black magic practices and focus on >>>>>>> things that really exist in this world -- SMT and CPU load. I've >>>>>>> dropped most of cache related things from the patch and made the >>>>>>> rest >>>>>>> of things more strict and predictable: >>>>>>> http://people.freebsd.org/~mav/sched.htt34.patch >>>>>> >>>>>> >>>>>> This looks great. I think there is value in considering the other >>>>>> approach further but I would like to do this part first. It would be >>>>>> nice to also add priority as a greater influence in the load >>>>>> balancing >>>>>> as well. >>>>> >>>>> >>>>> I haven't got good idea yet about balancing priorities, but I've >>>>> rewritten >>>>> balancer itself. As soon as sched_lowest() / sched_highest() are more >>>>> intelligent now, they allowed to remove topology traversing from the >>>>> balancer itself. That should fix double-swapping problem, allow to >>>>> keep >>>>> some >>>>> affinity while moving threads and make balancing more fair. I did >>>>> number >>>>> of >>>>> tests running 4, 8, 9 and 16 CPU-bound threads on 8 CPUs. With 4, 8 >>>>> and >>>>> 16 >>>>> threads everything is stationary as it should. With 9 threads I see >>>>> regular >>>>> and random load move between all 8 CPUs. Measurements on 5 minutes run >>>>> show >>>>> deviation of only about 5 seconds. It is the same deviation as I see >>>>> caused >>>>> by only scheduling of 16 threads on 8 cores without any balancing >>>>> needed >>>>> at >>>>> all. So I believe this code works as it should. >>>>> >>>>> Here is the patch: http://people.freebsd.org/~mav/sched.htt40.patch >>>>> >>>>> I plan this to be a final patch of this series (more to come :)) >>>>> and if >>>>> there will be no problems or objections, I am going to commit it >>>>> (except >>>>> some debugging KTRs) in about ten days. So now it's a good time for >>>>> reviews >>>>> and testing. :) >>>>> >>>> is there a place where all the patches are available ? >>> >>> >>> All my scheduler patches are cumulative, so all you need is only the >>> last >>> mentioned here sched.htt40.patch. >>> >> You may want to have a look to the result I collected in the >> `runs/freebsd-experiments' branch of: >> >> https://github.com/lacombar/hackbench/ >> >> and compare them with vanilla FreeBSD 9.0 and -CURRENT results >> available in `runs/freebsd'. On the dual package platform, your patch >> is not a definite win. >> >>> But in some cases, especially for multi-socket systems, to let it >>> show its >>> best, you may want to apply additional patch from avg@ to better >>> detect CPU >>> topology: >>> https://gitorious.org/~avg/freebsd/avgbsd/commit/6bca4a2e4854ea3fc275946a023db65c483cb9dd >>> >>> >> test I conducted specifically for this patch did not showed much >> improvement... > > If I understand right, this test runs thousands of threads sending and > receiving data over the pipes. It is quite likely that all CPUs will be > always busy and so load balancing is not really important in this test, > What looks good is that more complicated new code is not slower then old > one. > > While this test seems very scheduler-intensive, it may depend on many > other factors, such as syscall performance, context switch, etc. I'll > try to play more with it. My profiling on 8-core Core i7 system shows that code from sched_ule.c staying on first places consumes still only 13% of kernel CPU time, while doing million of context switches per second. cpu_search(), affected by this patch, even less -- only 8%. The rest of time is spread between many small other functions. I did some optimizations at r234066 to reduce cpu_search(0 time to 6%, but looking on how unstable results of this test are, hardly any difference there can be really measured by it. I have strong feeling that while this test may be interesting for profiling, it's own results in first place depend not from how fast scheduler is, but from the pipes capacity and other alike things. Can somebody hint me what except pipe capacity and context switch to unblocked receiver prevents sender from sending all data in batch and then receiver from receiving them all in batch? If different OSes have different policies there, I think results could be incomparable. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 9 20:30:21 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C2651065673 for ; Mon, 9 Apr 2012 20:30:21 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from mailout-us.mail.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id E864D8FC0C for ; Mon, 9 Apr 2012 20:30:20 +0000 (UTC) Received: (qmail 8393 invoked by uid 0); 9 Apr 2012 20:30:20 -0000 Received: from 67.206.184.8 by rms-us002.v300.gmx.net with HTTP Content-Type: text/plain; charset="utf-8" Date: Mon, 09 Apr 2012 16:30:17 -0400 From: "Dieter BSD" Message-ID: <20120409203019.155050@gmx.com> MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Authenticated: #74169980 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: jCPxb/Vd3zOlNR3dAHAhCgh+IGRvb0Cm Subject: Re: Graphical Terminal Environment X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 20:30:21 -0000 Brandon writes: > I'm still avidly trying to work on this idea, but right now the issue > seems to be with AMD and NVIDIA not documenting their protocols. Intel > does a good job, but I don't have any Intel chips with graphics laying > around. I thought that AMD had documented most of it by now, with the major exception of the UVD? > I'm working on a minimal GPU right now on an FPGA. > Currently it looks like I could run 4 monitors at 1080p for about $50 Have FPGA prices come down that much?  The OGP-D1 was quite a bit more than that, last time I looked.  Or would that be the price for a production version with an ASIC? From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 9 20:32:31 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E7F61065744 for ; Mon, 9 Apr 2012 20:32:31 +0000 (UTC) (envelope-from sushanth_rai@yahoo.com) Received: from nm4.bullet.mail.sp2.yahoo.com (nm4.bullet.mail.sp2.yahoo.com [98.139.91.74]) by mx1.freebsd.org (Postfix) with SMTP id 340A68FC20 for ; Mon, 9 Apr 2012 20:32:31 +0000 (UTC) Received: from [98.139.91.65] by nm4.bullet.mail.sp2.yahoo.com with NNFMP; 09 Apr 2012 20:32:25 -0000 Received: from [98.139.44.82] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 09 Apr 2012 20:32:25 -0000 Received: from [127.0.0.1] by omp1019.access.mail.sp2.yahoo.com with NNFMP; 09 Apr 2012 20:32:25 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 449626.47445.bm@omp1019.access.mail.sp2.yahoo.com Received: (qmail 66317 invoked by uid 60001); 9 Apr 2012 20:32:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1334003544; bh=JdtMGe22L7R3Gy/cpoHTh+DbYKz6tI3BVrUWneJEXZE=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=kP2cTt1DjvZAzBxV1qNKCoSNWt7vg692nTf7u/1SmbRdokLKOgi7k859EtaQzNV/pYxvS4zJvTNqgaEdiRc0B8sKGYDnXVsqADereabYhxV52FKiCWqRZZalefBEqnCmEzTbczMGrBiDlq24UaWhIF6cyPMjgQo0rKlrNZ/BV6c= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=UcAGA4iqHGT7d4XvQnxXCu4ODqGqZQdt+n34jpPA+stchbN5Bk6DAXtPAdExZxjr7cexoZbM9Msm6A4k4ToLlK2HMq1C5mi4BeIvGIzMq6bva8iUceu1r8CVSxJ45O7lCzO2Fg4rTBvRNt8Z0XapjAdlzaOBjHCJVnb7+y43Nts=; X-YMail-OSG: 6AkPAYEVM1mbP7V5VgDv8hjzjbp6Df2CDw4XaXd5_k_aODY eSpnPHsSYOE3NAZHyHg9g9HKlqPi6qAKX7pfmLZZJFIOYvriMo87i1KTupTV DgcBI8K5S7iqYBsV1wXwRD2y_q5BgIGC4XUm_VestHdUAm.bwADywkQIWmR_ br7MtoPCmjDtzTWBOO8kiDiNVIzYeFcvszp8bO_SbIjwCnMcQEdSEB4rtnxH qSVhHkvY0iDTIT5dNOsMr6jT_TTK39YnH.RPGVnU.qAUGvB9.RyWL86ezpRA VGyn4QTe4X3IjGYmHCGZoZmgzYqsKraqcllLFwD4PeR3T18DxyA3dCu75N4F FnISKhf1kpJM6EqBaaOfDb8ZH3bdNXD9D3CSzBfV2VWpug1huH2nC4ZXVJXV qI.piCm52bxa4OYkK69sCPgghM03OuaxuEp8Dn3XoUU_OGx1xWguqKze0IaL fytMDkoI- Received: from [209.119.38.67] by web180010.mail.gq1.yahoo.com via HTTP; Mon, 09 Apr 2012 13:32:24 PDT X-Mailer: YahooMailClassic/15.0.5 YahooMailWebService/0.8.117.340979 Message-ID: <1334003544.57349.YahooMailClassic@web180010.mail.gq1.yahoo.com> Date: Mon, 9 Apr 2012 13:32:24 -0700 (PDT) From: Sushanth Rai To: John Baldwin In-Reply-To: <201204091437.55505.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Startvation of realtime piority threads X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 20:32:31 -0000 I'm using stock 7.2. The priorities as defined in priority.h are in this ra= nge:=0A=0A/*=0A * Priorities range from 0 to 255, but differences of less t= hen 4 (RQ_PPQ)=0A * are insignificant. Ranges are as follows:=0A *=0A * In= terrupt threads: 0 - 63=0A * Top half kernel threads: 64 - 12= 7=0A * Realtime user threads: 128 - 159=0A * Time sharing user thread= s: 160 - 223=0A * Idle user threads: 224 - 255=0A *=0A * XXX If= /When the specific interrupt thread and top half thread ranges=0A * disappe= ar, a larger range can be used for user processes.=0A */=0A=0AThe trouble i= s with vm_waitpfault(), which explicitly sleeps at PUSER.=0A=0A=0ASushanth= =0A=0A--- On Mon, 4/9/12, John Baldwin wrote:=0A=0A> From= : John Baldwin =0A> Subject: Re: Startvation of realtime p= iority threads=0A> To: "Sushanth Rai" =0A> Cc: free= bsd-hackers@freebsd.org=0A> Date: Monday, April 9, 2012, 11:37 AM=0A> On Mo= nday, April 09, 2012 2:08:50 pm=0A> Sushanth Rai wrote:=0A> > I'm on 7.2. s= ched_sleep() on 7.2 just records the sleep=0A> time. That's why I =0A> thou= gh _sleep might the right place to do the check.=0A> =0A> Nah, sched_sleep(= ) is more accurate since the sleep priority=0A> can have other =0A> side ef= fects.=0A> =0A> Hmm, in stock 7.2, the rtprio range is below things like=0A= > PVM, etc., so that=0A> shouldn't actually be buggy in that regard.=A0 I f= ixed=0A> this in 9.0 and HEAD=0A> when I moved the rtprio range up above th= e kernel sleep=0A> priorities.=A0 Are=0A> you using local patches to 7.2 to= raise the priority of=0A> rtprio threads?=0A> =0A> > Thanks,=0A> > Sushant= h=0A> > =0A> > --- On Mon, 4/9/12, John Baldwin =0A> wrote= :=0A> > =0A> > > From: John Baldwin =0A> > > Subject: Re: = Startvation of realtime piority=0A> threads=0A> > > To: "Sushanth Rai" =0A> > > Cc: freebsd-hackers@freebsd.org=0A> > > Date: = Monday, April 9, 2012, 9:17 AM=0A> > > On Thursday, April 05, 2012 9:08:24= =0A> > > pm Sushanth Rai wrote:=0A> > > > I understand the downside of badl= y written=0A> realtime=0A> > > app.=A0 In my case =0A> > > application runs= in userspace without making much=0A> syscalls=0A> > > and by all means it = =0A> > > is a well behaved application. Yes, I can wire=0A> memory,=0A> > >= change the application =0A> > > to use mutex instead of spinlock and those= changes=0A> should=0A> > > help but they are =0A> > > still working around= the problem. I still believe=0A> kernel=0A> > > should not lower the =0A> = > > realtime priority when blocking on resources. This=0A> can lead=0A> > >= to priority =0A> > > inversion, especially since these threads run at=0A> = fixed=0A> > > priorities and kernel =0A> > > doesn't muck with them.=0A> > = > >=A0 =0A> > > > As you suggested _sleep() should not adjust=0A> the=0A> >= > priorities for realtime =0A> > > threads. =0A> > > =0A> > > Hmm, sched_s= leep() for both SCHED_4BSD and=0A> SCHED_ULE already=0A> > > does the right= =0A> > > thing here in HEAD.=0A> > > =0A> > >=A0 =A0=A0=A0if=0A> (PRI_BASE(= td->td_pri_class) !=3D=0A> > > PRI_TIMESHARE)=0A> > >=A0 =A0 =A0 =A0=A0=A0r= eturn;=0A> > > =0A> > > Which OS version did you see this on?=0A> > > =0A> = > > -- =0A> > > John Baldwin=0A> > > =0A> > =0A> =0A> -- =0A> John Baldwin= =0A> From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 10 02:37:12 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EF6B81065673 for ; Tue, 10 Apr 2012 02:37:12 +0000 (UTC) (envelope-from sushanth_rai@yahoo.com) Received: from nm20.bullet.mail.sp2.yahoo.com (nm20.bullet.mail.sp2.yahoo.com [98.139.91.90]) by mx1.freebsd.org (Postfix) with SMTP id AEF628FC18 for ; Tue, 10 Apr 2012 02:37:12 +0000 (UTC) Received: from [98.139.91.64] by nm20.bullet.mail.sp2.yahoo.com with NNFMP; 10 Apr 2012 02:37:12 -0000 Received: from [98.139.44.67] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 10 Apr 2012 02:37:12 -0000 Received: from [127.0.0.1] by omp1004.access.mail.sp2.yahoo.com with NNFMP; 10 Apr 2012 02:37:12 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 193849.89033.bm@omp1004.access.mail.sp2.yahoo.com Received: (qmail 5222 invoked by uid 60001); 10 Apr 2012 02:37:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1334025431; bh=FTdBq8vK0mYYL7OzYYfVAlC+sBnQW0vFehjb4cXxYDU=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=Jfwr+KJUC8+5wMZE+2a7Yc+Yh4NMOkj7OAJ5Q0l17lmmtHgbqbjRVApQEGzPh0v7aLWlSvgdZKTuGOe+NYUzLLbI9JSiRkbZVdFDctkmAW71D20dJvujGcg4nf/yHuHfWCCOU2utXGH6U80KIn7Fssd407EMEBspGLfpaJrMxGs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=ZzQ8Wk+7Tnr8ceIp+zmdwrMynM8/XKs2zgxOP0GEMNLufIkJQYfUwcYeIoB9ph2yRdW1D/hfwFa9UnKrF4Vc1JX9nV97sBdANj+QUU34TQNJtJnm6AcDNF+eod2m8MfV12jWNy4HXQKCJ/5znJKoPP51Z/DkySVF2IAT6OWmr40=; X-YMail-OSG: GldXdi4VM1kwL3tWjWWOOp4uT3OJu.ZTPUfo7OLOvVTLdGA xUp7GO0hEU5sRAyypB2nW4JOVC4QWC2n_.RpoOHUGXk8AZkMC2jkSMEpVnJg LzPv71X0Dyg_Gaa2xwDh45Yd1eD.z40HsBLdCmY8p1YoSeCZtt3hF0eqNwo8 aCZK5yBQ_R0xbwJnaKaNFvTRNZM6ss2r6uAo7UamhW2Snje4JdxfmWjNFst2 zcHJplaD_pv6Zpm9e.YUTucVSnHTIs0Ej41_RQyATNw0TWlnlPsXqFHINya. v.WbOOUr1TFeOyB6l68_OV9sVuLFcX8WTiKdVg69Ih4uCWzrbCUN9DPshBkW IIn_PSS3RVllZOU9rfR.SzGiR.YGH1PcMPa9wsdKWGnYfKMEwpjnZPKX23FQ dQh0N8tzokPgebB346QKY1eEe9oMbmY4_tXoPcpYaRzjDklHDK70Em7eqA7r MdaPNHR8- Received: from [209.119.38.67] by web180011.mail.gq1.yahoo.com via HTTP; Mon, 09 Apr 2012 19:37:11 PDT X-Mailer: YahooMailClassic/15.0.5 YahooMailWebService/0.8.117.340979 Message-ID: <1334025431.77315.YahooMailClassic@web180011.mail.gq1.yahoo.com> Date: Mon, 9 Apr 2012 19:37:11 -0700 (PDT) From: Sushanth Rai To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: mlockall() on freebsd 7.2 + amd64 returns EAGAIN X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 02:37:13 -0000 Hello, I have a simple program that links with the math library. The only thing that program does is to call mlockall(MCL_CURRENT | MCL_FUTURE). This call to mlockall fails with EAGAIN. I figured out that kernel vm_fault() is returning KERN_PROTECTION_FAILURE when it tries to fault-in the mmap'ed math library address. But I can't figure why. The /proc//map returns the following for the process: 0x800634000 0x80064c000 24 0 0xffffff0025571510 r-x 104 52 0x1000 COW NC vnode /lib/libm.so.5 0x80064c000 0x80064d000 1 0 0xffffff016f11c5e8 r-x 1 0 0x3100 COW NNC vnode /lib/libm.so.5 0x80064d000 0x80074c000 4 0 0xffffff0025571510 r-x 104 52 0x1000 COW NC vnode /lib/libm.so.5 Since ntpd calls mlockall with same option and links with math library too, I look at map o/p of ntpd, which looks slightly different "resident" column (3rd column) on 3rd line: 0x800682000 0x80069a000 8 0 0xffffff0025571510 r-x 100 50 0x1000 COW NC vnode /lib/libm.so.5 0x80069a000 0x80069b000 1 0 0xffffff0103b85870 r-x 1 0 0x3100 COW NNC vnode /lib/libm.so.5 0x80069b000 0x80079a000 0 0 0xffffff0025571510 r-x 100 50 0x1000 COW NC vnode /lib/libm.so.5 I don't know if that has anything to do with failure. The snippet of code that returns failure in vm_fault() is the following: if (fs.pindex >= fs.object->size) { unlock_and_deallocate(&fs); return (KERN_PROTECTION_FAILURE); } Any help would be appreciated. Thanks, Sushanth From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 10 08:04:17 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FC57106564A for ; Tue, 10 Apr 2012 08:04:17 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 046BF8FC08 for ; Tue, 10 Apr 2012 08:04:17 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1SHW3e-000EVv-1Q for freebsd-hackers@freebsd.org; Tue, 10 Apr 2012 11:04:10 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: freebsd-hackers@freebsd.org In-reply-to: References: Comments: In-reply-to Mark Felder message dated "Mon, 09 Apr 2012 10:36:34 -0500." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 10 Apr 2012 11:04:10 +0300 From: Daniel Braniss Message-ID: Subject: Re: time stops in vmware X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 08:04:17 -0000 > On Sun, 08 Apr 2012 02:11:25 -0500, Daniel Braniss > wrote: > > > Hi All > > There was some mention before that time stops under vmware, and now it's > > happened > > to me :-) > > > > the clock stopped now, the system is responsive, but eg > > sleep 1 > > never finishes. > > Is there a solution? > > btw, I'm running 8.2-stable, i'll try 8.3 soon. > > > > Can you recreate it? Does it go away if you use "kern.hz=200" in > loader.conf? We used to have to do that. no, I can't recreate it, could you? From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 10 09:57:45 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB749106566B for ; Tue, 10 Apr 2012 09:57:45 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 477C58FC12 for ; Tue, 10 Apr 2012 09:57:44 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q3A9vR6K009911; Tue, 10 Apr 2012 12:57:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q3A9vRBx056738; Tue, 10 Apr 2012 12:57:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q3A9vRMv056737; Tue, 10 Apr 2012 12:57:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 10 Apr 2012 12:57:26 +0300 From: Konstantin Belousov To: Sushanth Rai Message-ID: <20120410095726.GU2358@deviant.kiev.zoral.com.ua> References: <1334025431.77315.YahooMailClassic@web180011.mail.gq1.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Mj2Hoq6zy/C4bu/j" Content-Disposition: inline In-Reply-To: <1334025431.77315.YahooMailClassic@web180011.mail.gq1.yahoo.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org Subject: Re: mlockall() on freebsd 7.2 + amd64 returns EAGAIN X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 09:57:45 -0000 --Mj2Hoq6zy/C4bu/j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 09, 2012 at 07:37:11PM -0700, Sushanth Rai wrote: > Hello, >=20 > I have a simple program that links with the math library. The only thing = that program does is to call mlockall(MCL_CURRENT | MCL_FUTURE). This call = to mlockall fails with EAGAIN. I figured out that kernel vm_fault() is retu= rning KERN_PROTECTION_FAILURE when it tries to fault-in the mmap'ed math li= brary address. But I can't figure why. >=20 > The /proc//map returns the following for the process: >=20 > 0x800634000 0x80064c000 24 0 0xffffff0025571510 r-x 104 52 0x1000 COW NC = vnode /lib/libm.so.5 > 0x80064c000 0x80064d000 1 0 0xffffff016f11c5e8 r-x 1 0 0x3100 COW NNC vno= de /lib/libm.so.5 > 0x80064d000 0x80074c000 4 0 0xffffff0025571510 r-x 104 52 0x1000 COW NC v= node /lib/libm.so.5 >=20 > Since ntpd calls mlockall with same option and links with math library to= o, I look at map o/p of ntpd, which looks slightly different "resident" col= umn (3rd column) on 3rd line: > 0x800682000 0x80069a000 8 0 0xffffff0025571510 r-x 100 50 0x1000 COW NC v= node /lib/libm.so.5 > 0x80069a000 0x80069b000 1 0 0xffffff0103b85870 r-x 1 0 0x3100 COW NNC vno= de /lib/libm.so.5 > 0x80069b000 0x80079a000 0 0 0xffffff0025571510 r-x 100 50 0x1000 COW NC v= node /lib/libm.so.5 >=20 > I don't know if that has anything to do with failure. The snippet of code= that returns failure in vm_fault() is the following: >=20 > if (fs.pindex >=3D fs.object->size) { > unlock_and_deallocate(&fs); > return (KERN_PROTECTION_FAILURE); > } >=20 > Any help would be appreciated. This might be a bug fixed in r191810, but I am not sure. --Mj2Hoq6zy/C4bu/j Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+EBAYACgkQC3+MBN1Mb4j/rwCfUuRzzcpojQKcbf3Awqug6XM4 zWIAoIg3OXTe5bLFWJ4y7UX7BDchPl5f =kr3c -----END PGP SIGNATURE----- --Mj2Hoq6zy/C4bu/j-- From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 10 13:58:30 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 85E711065673 for ; Tue, 10 Apr 2012 13:58:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5C3658FC08 for ; Tue, 10 Apr 2012 13:58:30 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id AB52CB9A9; Tue, 10 Apr 2012 09:58:29 -0400 (EDT) From: John Baldwin To: Sushanth Rai Date: Tue, 10 Apr 2012 09:57:39 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <1334003544.57349.YahooMailClassic@web180010.mail.gq1.yahoo.com> In-Reply-To: <1334003544.57349.YahooMailClassic@web180010.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201204100957.39465.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 10 Apr 2012 09:58:29 -0400 (EDT) Cc: freebsd-hackers@freebsd.org Subject: Re: Startvation of realtime piority threads X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 13:58:30 -0000 On Monday, April 09, 2012 4:32:24 pm Sushanth Rai wrote: > I'm using stock 7.2. The priorities as defined in priority.h are in this range: > > /* > * Priorities range from 0 to 255, but differences of less then 4 (RQ_PPQ) > * are insignificant. Ranges are as follows: > * > * Interrupt threads: 0 - 63 > * Top half kernel threads: 64 - 127 > * Realtime user threads: 128 - 159 > * Time sharing user threads: 160 - 223 > * Idle user threads: 224 - 255 > * > * XXX If/When the specific interrupt thread and top half thread ranges > * disappear, a larger range can be used for user processes. > */ > > The trouble is with vm_waitpfault(), which explicitly sleeps at PUSER. Ah, yes, PUSER is the one Pxxx not in "top half kernel threads". You can patch that locally, but you may have better lucking using 9.0 (or backporting my fixes in 9.0 back to 7 or 8). They were too invasive to backport to FreeBSD 7/8, but you could still do it locally (I've used them at work on both 7 and 8). -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 10 16:27:10 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 63B541065672; Tue, 10 Apr 2012 16:27:10 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh5.mail.rice.edu (mh5.mail.rice.edu [128.42.199.32]) by mx1.freebsd.org (Postfix) with ESMTP id 25FB58FC12; Tue, 10 Apr 2012 16:27:10 +0000 (UTC) Received: from mh5.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh5.mail.rice.edu (Postfix) with ESMTP id A9329290FC6; Tue, 10 Apr 2012 11:19:41 -0500 (CDT) Received: from mh5.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh5.mail.rice.edu (Postfix) with ESMTP id 819F92910FB; Tue, 10 Apr 2012 11:19:41 -0500 (CDT) X-Virus-Scanned: by amavis-2.6.4 at mh5.mail.rice.edu, auth channel Received: from mh5.mail.rice.edu ([127.0.0.1]) by mh5.mail.rice.edu (mh5.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id UQAxHqmGAfai; Tue, 10 Apr 2012 11:19:41 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh5.mail.rice.edu (Postfix) with ESMTPSA id 931C1290FC6; Tue, 10 Apr 2012 11:19:40 -0500 (CDT) Message-ID: <4F845D9B.10004@rice.edu> Date: Tue, 10 Apr 2012 11:19:39 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:8.0) Gecko/20111113 Thunderbird/8.0 MIME-Version: 1.0 To: John Baldwin References: <4F7B495D.3010402@zonov.org> <20120404071746.GJ2358@deviant.kiev.zoral.com.ua> <4F7DC037.9060803@rice.edu> <201204091126.25260.jhb@freebsd.org> In-Reply-To: <201204091126.25260.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, Andrey Zonov , alc@freebsd.org Subject: Re: problems with mmap() and disk caching X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 16:27:10 -0000 On 04/09/2012 10:26, John Baldwin wrote: > On Thursday, April 05, 2012 11:54:31 am Alan Cox wrote: >> On 04/04/2012 02:17, Konstantin Belousov wrote: >>> On Tue, Apr 03, 2012 at 11:02:53PM +0400, Andrey Zonov wrote: >>>> Hi, >>>> >>>> I open the file, then call mmap() on the whole file and get pointer, >>>> then I work with this pointer. I expect that page should be only once >>>> touched to get it into the memory (disk cache?), but this doesn't work! >>>> >>>> I wrote the test (attached) and ran it for the 1G file generated from >>>> /dev/random, the result is the following: >>>> >>>> Prepare file: >>>> # swapoff -a >>>> # newfs /dev/ada0b >>>> # mount /dev/ada0b /mnt >>>> # dd if=/dev/random of=/mnt/random-1024 bs=1m count=1024 >>>> >>>> Purge cache: >>>> # umount /mnt >>>> # mount /dev/ada0b /mnt >>>> >>>> Run test: >>>> $ ./mmap /mnt/random-1024 30 >>>> mmap: 1 pass took: 7.431046 (none: 262112; res: 32; super: >>>> 0; other: 0) >>>> mmap: 2 pass took: 7.356670 (none: 261648; res: 496; super: >>>> 0; other: 0) >>>> mmap: 3 pass took: 7.307094 (none: 260521; res: 1623; super: >>>> 0; other: 0) >>>> mmap: 4 pass took: 7.350239 (none: 258904; res: 3240; super: >>>> 0; other: 0) >>>> mmap: 5 pass took: 7.392480 (none: 257286; res: 4858; super: >>>> 0; other: 0) >>>> mmap: 6 pass took: 7.292069 (none: 255584; res: 6560; super: >>>> 0; other: 0) >>>> mmap: 7 pass took: 7.048980 (none: 251142; res: 11002; super: >>>> 0; other: 0) >>>> mmap: 8 pass took: 6.899387 (none: 247584; res: 14560; super: >>>> 0; other: 0) >>>> mmap: 9 pass took: 7.190579 (none: 242992; res: 19152; super: >>>> 0; other: 0) >>>> mmap: 10 pass took: 6.915482 (none: 239308; res: 22836; super: >>>> 0; other: 0) >>>> mmap: 11 pass took: 6.565909 (none: 232835; res: 29309; super: >>>> 0; other: 0) >>>> mmap: 12 pass took: 6.423945 (none: 226160; res: 35984; super: >>>> 0; other: 0) >>>> mmap: 13 pass took: 6.315385 (none: 208555; res: 53589; super: >>>> 0; other: 0) >>>> mmap: 14 pass took: 6.760780 (none: 192805; res: 69339; super: >>>> 0; other: 0) >>>> mmap: 15 pass took: 5.721513 (none: 174497; res: 87647; super: >>>> 0; other: 0) >>>> mmap: 16 pass took: 5.004424 (none: 155938; res: 106206; super: >>>> 0; other: 0) >>>> mmap: 17 pass took: 4.224926 (none: 135639; res: 126505; super: >>>> 0; other: 0) >>>> mmap: 18 pass took: 3.749608 (none: 117952; res: 144192; super: >>>> 0; other: 0) >>>> mmap: 19 pass took: 3.398084 (none: 99066; res: 163078; super: >>>> 0; other: 0) >>>> mmap: 20 pass took: 3.029557 (none: 74994; res: 187150; super: >>>> 0; other: 0) >>>> mmap: 21 pass took: 2.379430 (none: 55231; res: 206913; super: >>>> 0; other: 0) >>>> mmap: 22 pass took: 2.046521 (none: 40786; res: 221358; super: >>>> 0; other: 0) >>>> mmap: 23 pass took: 1.152797 (none: 30311; res: 231833; super: >>>> 0; other: 0) >>>> mmap: 24 pass took: 0.972617 (none: 16196; res: 245948; super: >>>> 0; other: 0) >>>> mmap: 25 pass took: 0.577515 (none: 8286; res: 253858; super: >>>> 0; other: 0) >>>> mmap: 26 pass took: 0.380738 (none: 3712; res: 258432; super: >>>> 0; other: 0) >>>> mmap: 27 pass took: 0.253583 (none: 1193; res: 260951; super: >>>> 0; other: 0) >>>> mmap: 28 pass took: 0.157508 (none: 0; res: 262144; super: >>>> 0; other: 0) >>>> mmap: 29 pass took: 0.156169 (none: 0; res: 262144; super: >>>> 0; other: 0) >>>> mmap: 30 pass took: 0.156550 (none: 0; res: 262144; super: >>>> 0; other: 0) >>>> >>>> If I ran this: >>>> $ cat /mnt/random-1024> /dev/null >>>> before test, when result is the following: >>>> >>>> $ ./mmap /mnt/random-1024 5 >>>> mmap: 1 pass took: 0.337657 (none: 0; res: 262144; super: >>>> 0; other: 0) >>>> mmap: 2 pass took: 0.186137 (none: 0; res: 262144; super: >>>> 0; other: 0) >>>> mmap: 3 pass took: 0.186132 (none: 0; res: 262144; super: >>>> 0; other: 0) >>>> mmap: 4 pass took: 0.186535 (none: 0; res: 262144; super: >>>> 0; other: 0) >>>> mmap: 5 pass took: 0.190353 (none: 0; res: 262144; super: >>>> 0; other: 0) >>>> >>>> This is what I expect. But why this doesn't work without reading file >>>> manually? >>> Issue seems to be in some change of the behaviour of the reserv or >>> phys allocator. I Cc:ed Alan. >> I'm pretty sure that the behavior here hasn't significantly changed in >> about twelve years. Otherwise, I agree with your analysis. >> >> On more than one occasion, I've been tempted to change: >> >> pmap_remove_all(mt); >> if (mt->dirty != 0) >> vm_page_deactivate(mt); >> else >> vm_page_cache(mt); >> >> to: >> >> vm_page_dontneed(mt); >> >> because I suspect that the current code does more harm than good. In >> theory, it saves activations of the page daemon. However, more often >> than not, I suspect that we are spending more on page reactivations than >> we are saving on page daemon activations. The sequential access >> detection heuristic is just too easily triggered. For example, I've >> seen it triggered by demand paging of the gcc text segment. Also, I >> think that pmap_remove_all() and especially vm_page_cache() are too >> severe for a detection heuristic that is so easily triggered. > Are you planning to commit this? > Not yet. I did some tests with a file that was several times larger than DRAM, and I didn't like what I saw. Initially, everything behaved as expected, but about halfway through the test the bulk of the pages were active. Despite the call to pmap_clear_reference() in vm_page_dontneed(), the page daemon is finding the pages to be referenced and reactivating them. The net result is that the time it takes to read the file (from a relatively fast SSD) goes up by about 12%. So, this still needs work. Alan From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 10 16:58:08 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3380106566B; Tue, 10 Apr 2012 16:58:08 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id C65FB8FC15; Tue, 10 Apr 2012 16:58:07 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so3262108wgb.1 for ; Tue, 10 Apr 2012 09:58:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q59w+zPOdamhK5KD4i7+Met1rRSz08k2Hp9St4xYIsk=; b=tusW4L9pAPzw8AKA2Bt4Nz0xRlFhnOXOKM8VxgSBzRFMbVYwGPBHzs3TnaQP/fz3d+ HhL2rK6TN6b/uGRb6rfvv6BfKMdjS5V8+UJ7xnZ1cB/e6dWF9QE5AEz910zR2ofcTBFO 94Dx0euDJ0EolEx7A0lM7XUI8q07cvBW1dZeDIU1MURqlVUgrtmFeHaUU5nWQ1ovvWIG qPVc1MlNTTQKunWQeX0MNYKEwy9jkpaGFi8mbGhd1FlOUAEJ9WQ6alUqY6TM0SSVwwT2 EwMbzhahnMo3QoYbul7a5kWpAPi0DM8ygA1oudXBQSJhIOuemd655IH/h4CHgM+gDFbZ 33Cg== MIME-Version: 1.0 Received: by 10.180.105.194 with SMTP id go2mr8674414wib.22.1334077081135; Tue, 10 Apr 2012 09:58:01 -0700 (PDT) Received: by 10.216.49.81 with HTTP; Tue, 10 Apr 2012 09:58:00 -0700 (PDT) In-Reply-To: <4F833F3D.7070106@FreeBSD.org> References: <4F2F7B7F.40508@FreeBSD.org> <4F366E8F.9060207@FreeBSD.org> <4F367965.6000602@FreeBSD.org> <4F396B24.5090602@FreeBSD.org> <4F3978BC.6090608@FreeBSD.org> <4F3990EA.1080002@FreeBSD.org> <4F3C0BB9.6050101@FreeBSD.org> <4F3E807A.60103@FreeBSD.org> <4F3E8858.4000001@FreeBSD.org> <4F7DE863.6080607@FreeBSD.org> <4F833F3D.7070106@FreeBSD.org> Date: Tue, 10 Apr 2012 12:58:00 -0400 Message-ID: From: Arnaud Lacombe To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, Florian Smeets , Jeff Roberson , Andriy Gapon , FreeBSD current Subject: Re: [RFT][patch] Scheduling for HTT and not only X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 16:58:09 -0000 Hi, 2012/4/9 Alexander Motin : > [...] > > I have strong feeling that while this test may be interesting for profiling, > it's own results in first place depend not from how fast scheduler is, but > from the pipes capacity and other alike things. Can somebody hint me what > except pipe capacity and context switch to unblocked receiver prevents > sender from sending all data in batch and then receiver from receiving them > all in batch? If different OSes have different policies there, I think > results could be incomparable. > Let me disagree on your conclusion. If OS A does a task in X seconds, and OS B does the same task in Y seconds, if Y > X, then OS B is just not performing good enough. Internal implementation's difference for the task can not be waived as an excuse for result's comparability. - Arnaud From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 10 17:08:58 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E95F91065672 for ; Tue, 10 Apr 2012 17:08:58 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from mailout-us.gmx.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id B806F8FC17 for ; Tue, 10 Apr 2012 17:08:58 +0000 (UTC) Received: (qmail 31510 invoked by uid 0); 10 Apr 2012 17:08:57 -0000 Received: from 67.206.161.58 by rms-us006.v300.gmx.net with HTTP Content-Type: text/plain; charset="utf-8" Date: Tue, 10 Apr 2012 13:08:54 -0400 From: "Dieter BSD" Message-ID: <20120410170855.155050@gmx.com> MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Authenticated: #74169980 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: cAz2b/Vd3zOlNR3dAHAhnVd+IGRvbwBL Subject: mlock/mlockall (was: Re: problems with mmap() and disk caching) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 17:08:59 -0000 Andrey writes: > Wired memory: kernel memory and yes, application may get wired memory > through mlock()/mlockall(), but I haven't seen any real application > which calls mlock(). Apps with real time considerations may need to lock memory to prevent having to wait for page/swap. From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 10 17:18:51 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 744A0106564A; Tue, 10 Apr 2012 17:18:51 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5BCFC8FC08; Tue, 10 Apr 2012 17:18:50 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so26764bkc.13 for ; Tue, 10 Apr 2012 10:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=sfxBaRLiTNEGpdNHeefap/2DUvIvlLnDr1GFdM3chFg=; b=I4RcuaAM+kOlF68rSHIs7DO1YVtX9Hz4nqSWE0dGRfnGEqSVG8yDsR7Oo1HYS5KrJ3 CdZDi8tTEyJenuwhKPiUwiyRj/u1LrRnvvApWQh+OBJSo6wgSFSEgZzoeTpMnIBzVwJZ 17SrTW1LZTOLFwUrSANTwbvKXgWKrv3Q4eVrpPvzVfPpbIwKh5TvRoDKZ3qxx3lwWkoo WYNz5Pec8TB6MVCKoRHO3ZCVH+ZpQWX9qyWEXPnvbZrMGeYv2t+bF6VQCcLdrMvtsBvH CwSewb1got7r/2hcZP6b+0zRxJUx848EHSSiVqwFKWIf38nIo6CV5qzhWRrOLVjocAmI 074w== Received: by 10.205.130.12 with SMTP id hk12mr5201606bkc.76.1334078329126; Tue, 10 Apr 2012 10:18:49 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id iv11sm33330488bkc.16.2012.04.10.10.18.45 (version=SSLv3 cipher=OTHER); Tue, 10 Apr 2012 10:18:47 -0700 (PDT) Sender: Alexander Motin Message-ID: <4F846B74.9080504@FreeBSD.org> Date: Tue, 10 Apr 2012 20:18:44 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120226 Thunderbird/10.0.2 MIME-Version: 1.0 To: Arnaud Lacombe References: <4F2F7B7F.40508@FreeBSD.org> <4F366E8F.9060207@FreeBSD.org> <4F367965.6000602@FreeBSD.org> <4F396B24.5090602@FreeBSD.org> <4F3978BC.6090608@FreeBSD.org> <4F3990EA.1080002@FreeBSD.org> <4F3C0BB9.6050101@FreeBSD.org> <4F3E807A.60103@FreeBSD.org> <4F3E8858.4000001@FreeBSD.org> <4F7DE863.6080607@FreeBSD.org> <4F833F3D.7070106@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Florian Smeets , Jeff Roberson , Andriy Gapon , FreeBSD current Subject: Re: [RFT][patch] Scheduling for HTT and not only X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 17:18:51 -0000 On 04/10/12 19:58, Arnaud Lacombe wrote: > 2012/4/9 Alexander Motin: >> [...] >> >> I have strong feeling that while this test may be interesting for profiling, >> it's own results in first place depend not from how fast scheduler is, but >> from the pipes capacity and other alike things. Can somebody hint me what >> except pipe capacity and context switch to unblocked receiver prevents >> sender from sending all data in batch and then receiver from receiving them >> all in batch? If different OSes have different policies there, I think >> results could be incomparable. >> > Let me disagree on your conclusion. If OS A does a task in X seconds, > and OS B does the same task in Y seconds, if Y> X, then OS B is just > not performing good enough. Internal implementation's difference for > the task can not be waived as an excuse for result's comparability. Sure, numbers are always numbers, but the question is what are they showing? Understanding of the test results is even more important for purely synthetic tests like this. Especially when one test run gives 25 seconds, while another gives 50. This test is not completely clear to me and that is what I've told. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 10 17:21:57 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CADA106564A for ; Tue, 10 Apr 2012 17:21:57 +0000 (UTC) (envelope-from sushanth_rai@yahoo.com) Received: from nm25-vm0.bullet.mail.sp2.yahoo.com (nm25-vm0.bullet.mail.sp2.yahoo.com [98.139.91.228]) by mx1.freebsd.org (Postfix) with SMTP id 711478FC08 for ; Tue, 10 Apr 2012 17:21:57 +0000 (UTC) Received: from [98.139.91.70] by nm25.bullet.mail.sp2.yahoo.com with NNFMP; 10 Apr 2012 17:21:57 -0000 Received: from [98.139.44.66] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 10 Apr 2012 17:21:57 -0000 Received: from [127.0.0.1] by omp1003.access.mail.sp2.yahoo.com with NNFMP; 10 Apr 2012 17:21:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 186529.38023.bm@omp1003.access.mail.sp2.yahoo.com Received: (qmail 71065 invoked by uid 60001); 10 Apr 2012 17:21:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1334078516; bh=NK22YYV5N9tBpfdPmHjRo2iYSribMSWIlO8q+zHEtMg=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=vH47c4wZA2V6RrbLHLnRgB/fMEXgzcgEoZRUUGqHevB1SUH+45n7JRoAUn8uPnW72piipG/sZIBFdrqMZ2prKoUw4J9EsxygA3HUWUKtqHPylmXkGr1n7kXvp2YcZ3HVnYbkl67841ypzVWXz6VJKNIMH7KFFbD0kZyksHTqrvA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=e2Ch2lvAz5jc7Trj5P9jkzqFMGYmAi26KSq9CBeXBnMYkyx4AR9g+10ctJHX0+QRIUNwpwglRX6ljWBvYBNE/NGbBVrnFOXiPAHGnluW6VF3j/5K4PvYh9z8GeQGB6X+MGG/Ue0EpzKPoype68SuDJKzC7z8tBBMpmB8JHuePZI=; X-YMail-OSG: UFFLeRIVM1kbO6WKRRaHa1jy7EFrZWhB8pGjQBWlUjz83VH _cmFc8jks6S15TZqkcqgzztDVt6ojSomM.QQ6VfYcQKNl8YfL6_BhebwQZHk VhPatYPnIN9bzzVFPAKyDnLkuLhpM_Wk5zaHrz6iRAdYSsEY64kXHZRYpHvn B0z.DExioEO7bZflWtK7dxCifPwl2UAlwdGdhSAovqycruF0FdL.RFY81o9M edIPi3fMEkyt7IJVTkOqkAnhL_J3kJOgSPMM9.ykjdeX1wiEFzFOMCouv9U6 6TR59g0BiwNJrhdQzaQizlcXEcVOcU8yc9tvSu.igq1cWqHNh04t4RKkvbpG SvyUFyHZP8tzLpGKcSVuRIrkcZTve7IESTtsUQMS0A56akL6a3JOVnqij6Rn kCACbu.RLW_ITy3qBeML4LIpSDO73CSIj.xq9ul_AlMVjlMemfXj0Z4Y1iHX XsNWk Received: from [75.62.238.5] by web180014.mail.gq1.yahoo.com via HTTP; Tue, 10 Apr 2012 10:21:52 PDT X-Mailer: YahooMailClassic/15.0.5 YahooMailWebService/0.8.117.340979 Message-ID: <1334078512.27271.YahooMailClassic@web180014.mail.gq1.yahoo.com> Date: Tue, 10 Apr 2012 10:21:52 -0700 (PDT) From: Sushanth Rai To: John Baldwin In-Reply-To: <201204100957.39465.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Startvation of realtime piority threads X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 17:21:57 -0000 Thanks. I'll try to back port locally.=0A=0ASushanth=0A=0A--- On Tue, 4/10/= 12, John Baldwin wrote:=0A=0A> From: John Baldwin =0A> Subject: Re: Startvation of realtime piority threads=0A> To:= "Sushanth Rai" =0A> Cc: freebsd-hackers@freebsd.or= g=0A> Date: Tuesday, April 10, 2012, 6:57 AM=0A> On Monday, April 09, 2012 = 4:32:24 pm=0A> Sushanth Rai wrote:=0A> > I'm using stock 7.2. The prioritie= s as defined in=0A> priority.h are in this range:=0A> > =0A> > /*=0A> >=A0 = * Priorities range from 0 to 255, but differences=0A> of less then 4 (RQ_PP= Q)=0A> >=A0 * are insignificant.=A0 Ranges are as=0A> follows:=0A> >=A0 *= =0A> >=A0 * Interrupt threads:=A0 =A0 =A0 =A0=0A> =A0=A0=A00 - 63=0A> >=A0 = * Top half kernel threads:=A0=0A> =A0=A0=A064 - 127=0A> >=A0 * Realtime use= r threads:=A0 =A0=0A> =A0=A0=A0128 - 159=0A> >=A0 * Time sharing user threa= ds:=A0=A0=A0160=0A> - 223=0A> >=A0 * Idle user threads:=A0 =A0 =A0 =A0=0A> = =A0=A0=A0224 - 255=0A> >=A0 *=0A> >=A0 * XXX If/When the specific interrupt= thread and=0A> top half thread ranges=0A> >=A0 * disappear, a larger range= can be used for user=0A> processes.=0A> >=A0 */=0A> > =0A> > The trouble i= s with vm_waitpfault(), which explicitly=0A> sleeps at PUSER.=0A> =0A> Ah, = yes, PUSER is the one Pxxx not in "top half kernel=0A> threads".=A0 You can= patch=0A> that locally, but you may have better lucking using 9.0 (or=0A> = backporting my=0A> fixes in 9.0 back to 7 or 8).=A0 They were too invasive= =0A> to backport to FreeBSD=0A> 7/8, but you could still do it locally (I'v= e used them at=0A> work on both 7 and 8).=0A> =0A> -- =0A> John Baldwin=0A>= _______________________________________________=0A> freebsd-hackers@freebs= d.org=0A> mailing list=0A> http://lists.freebsd.org/mailman/listinfo/freebs= d-hackers=0A> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe= @freebsd.org"=0A> From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 10 17:54:05 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E47301065672; Tue, 10 Apr 2012 17:54:04 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id CD77F8FC0A; Tue, 10 Apr 2012 17:54:03 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so62269bkc.13 for ; Tue, 10 Apr 2012 10:54:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=w9e/XgRJ3FTzoNhcbo6H0mrdvrDyCVpcWzvKgqWYpC4=; b=nEyTHXKnQ/zWvo5vY4TL9hXlL/v5hpJ8iK6RlAFXf1JMqLkPo26UgKEU2gvC66gLO2 gDB4JAIn7uKclOsknsEWkCeyFPSHdbW1/CLJ0bNivpg+a5JwqMzQuB2O6VXkON6vfe4v BhEQLOG+2QP/ty3uUa82miLzpewQNe+Nk0DpVPUAn/4Ne9MMNv7wboFsh3yF3Zx+EReq q0Xym5/+lZMK0vlvxSp31+ejP9I2WbPjSlyVGve3aNkoKgze2lavGsN9ZwCjd9Q2PHB+ au6cpZ8NTfA8xBMCHusPi0g/PbmQ4TaejRWUMHB2eoJWF3cvvHOhpi0XWVwaj8wp4Lws jm5Q== Received: by 10.205.139.77 with SMTP id iv13mr5022765bkc.91.1334080442881; Tue, 10 Apr 2012 10:54:02 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id f11sm50845bkw.6.2012.04.10.10.54.00 (version=SSLv3 cipher=OTHER); Tue, 10 Apr 2012 10:54:01 -0700 (PDT) Sender: Alexander Motin Message-ID: <4F8473B7.9080000@FreeBSD.org> Date: Tue, 10 Apr 2012 20:53:59 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120226 Thunderbird/10.0.2 MIME-Version: 1.0 To: Arnaud Lacombe References: <4F2F7B7F.40508@FreeBSD.org> <4F366E8F.9060207@FreeBSD.org> <4F367965.6000602@FreeBSD.org> <4F396B24.5090602@FreeBSD.org> <4F3978BC.6090608@FreeBSD.org> <4F3990EA.1080002@FreeBSD.org> <4F3C0BB9.6050101@FreeBSD.org> <4F3E807A.60103@FreeBSD.org> <4F3E8858.4000001@FreeBSD.org> <4F7DE863.6080607@FreeBSD.org> <4F833F3D.7070106@FreeBSD.org> <4F846B74.9080504@FreeBSD.org> In-Reply-To: <4F846B74.9080504@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Florian Smeets , Jeff Roberson , Andriy Gapon , FreeBSD current Subject: Re: [RFT][patch] Scheduling for HTT and not only X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 17:54:05 -0000 On 04/10/12 20:18, Alexander Motin wrote: > On 04/10/12 19:58, Arnaud Lacombe wrote: >> 2012/4/9 Alexander Motin: >>> [...] >>> >>> I have strong feeling that while this test may be interesting for >>> profiling, >>> it's own results in first place depend not from how fast scheduler >>> is, but >>> from the pipes capacity and other alike things. Can somebody hint me >>> what >>> except pipe capacity and context switch to unblocked receiver prevents >>> sender from sending all data in batch and then receiver from >>> receiving them >>> all in batch? If different OSes have different policies there, I think >>> results could be incomparable. >>> >> Let me disagree on your conclusion. If OS A does a task in X seconds, >> and OS B does the same task in Y seconds, if Y> X, then OS B is just >> not performing good enough. Internal implementation's difference for >> the task can not be waived as an excuse for result's comparability. > > Sure, numbers are always numbers, but the question is what are they > showing? Understanding of the test results is even more important for > purely synthetic tests like this. Especially when one test run gives 25 > seconds, while another gives 50. This test is not completely clear to me > and that is what I've told. Small illustration to my point. Simple scheduler tuning affects thread preemption policy and changes this test results in three times: mav@test:/test/hackbench# ./hackbench 30 process 1000 Running with 30*40 (== 1200) tasks. Time: 9.568 mav@test:/test/hackbench# sysctl kern.sched.interact=0 kern.sched.interact: 30 -> 0 mav@test:/test/hackbench# ./hackbench 30 process 1000 Running with 30*40 (== 1200) tasks. Time: 5.163 mav@test:/test/hackbench# sysctl kern.sched.interact=100 kern.sched.interact: 0 -> 100 mav@test:/test/hackbench# ./hackbench 30 process 1000 Running with 30*40 (== 1200) tasks. Time: 3.190 I think it affects balance between pipe latency and bandwidth, while test measures only the last. It is clear that conclusion from these numbers depends on what do we want to have. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 10 18:46:13 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 07692106566C; Tue, 10 Apr 2012 18:46:13 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id C64AB8FC1B; Tue, 10 Apr 2012 18:46:11 +0000 (UTC) Received: by wibhj6 with SMTP id hj6so3197055wib.13 for ; Tue, 10 Apr 2012 11:46:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uyANYuAOOuvJOODLHG0VXES5rpeIfoiYAu3bRUI3ZC4=; b=Wea4h6iP3sClRs8fPlupqAI6d1iHzQA/2gbd1f9gQYFfxe4VTlJYmw/19dLjwLKOGI Q/VIwfoaBaULXYHg9FkNTsYl2mL/9/a87oVQiUuV+MdXIudq3TWFxbaJHbwJ/ZXCoR9F 641877BTSNemyPqCQSeKKYhAb5R2h9PWFnpaQT9XiCi/xDNk4eFT4yeHuDPvbKMpapyR 1gGgMHmZf2dUceRfuXrZxP1UQUlD2AFken0L560q2/b36Sr92BgeguRvH19IUejs6ayK Ajnl9kxiKp/CfV5nZac/gj4+wxZSApNIChCMLvWnKhsG3jYx3b9SFx0KvmUWW1z45Jbm M39Q== MIME-Version: 1.0 Received: by 10.180.88.164 with SMTP id bh4mr9343064wib.22.1334083570443; Tue, 10 Apr 2012 11:46:10 -0700 (PDT) Received: by 10.216.49.81 with HTTP; Tue, 10 Apr 2012 11:46:10 -0700 (PDT) In-Reply-To: <4F8473B7.9080000@FreeBSD.org> References: <4F2F7B7F.40508@FreeBSD.org> <4F366E8F.9060207@FreeBSD.org> <4F367965.6000602@FreeBSD.org> <4F396B24.5090602@FreeBSD.org> <4F3978BC.6090608@FreeBSD.org> <4F3990EA.1080002@FreeBSD.org> <4F3C0BB9.6050101@FreeBSD.org> <4F3E807A.60103@FreeBSD.org> <4F3E8858.4000001@FreeBSD.org> <4F7DE863.6080607@FreeBSD.org> <4F833F3D.7070106@FreeBSD.org> <4F846B74.9080504@FreeBSD.org> <4F8473B7.9080000@FreeBSD.org> Date: Tue, 10 Apr 2012 14:46:10 -0400 Message-ID: From: Arnaud Lacombe To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, Florian Smeets , Jeff Roberson , Andriy Gapon , FreeBSD current Subject: Re: [RFT][patch] Scheduling for HTT and not only X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 18:46:13 -0000 Hi, On Tue, Apr 10, 2012 at 1:53 PM, Alexander Motin wrote: > On 04/10/12 20:18, Alexander Motin wrote: >> >> On 04/10/12 19:58, Arnaud Lacombe wrote: >>> >>> 2012/4/9 Alexander Motin: >>>> >>>> [...] >>>> >>>> I have strong feeling that while this test may be interesting for >>>> profiling, >>>> it's own results in first place depend not from how fast scheduler >>>> is, but >>>> from the pipes capacity and other alike things. Can somebody hint me >>>> what >>>> except pipe capacity and context switch to unblocked receiver prevents >>>> sender from sending all data in batch and then receiver from >>>> receiving them >>>> all in batch? If different OSes have different policies there, I think >>>> results could be incomparable. >>>> >>> Let me disagree on your conclusion. If OS A does a task in X seconds, >>> and OS B does the same task in Y seconds, if Y> X, then OS B is just >>> not performing good enough. Internal implementation's difference for >>> the task can not be waived as an excuse for result's comparability. >> >> >> Sure, numbers are always numbers, but the question is what are they >> showing? Understanding of the test results is even more important for >> purely synthetic tests like this. Especially when one test run gives 25 >> seconds, while another gives 50. This test is not completely clear to me >> and that is what I've told. > > Small illustration to my point. Simple scheduler tuning affects thread > preemption policy and changes this test results in three times: > > mav@test:/test/hackbench# ./hackbench 30 process 1000 > Running with 30*40 (== 1200) tasks. > Time: 9.568 > > mav@test:/test/hackbench# sysctl kern.sched.interact=0 > kern.sched.interact: 30 -> 0 > mav@test:/test/hackbench# ./hackbench 30 process 1000 > Running with 30*40 (== 1200) tasks. > Time: 5.163 > > mav@test:/test/hackbench# sysctl kern.sched.interact=100 > kern.sched.interact: 0 -> 100 > mav@test:/test/hackbench# ./hackbench 30 process 1000 > Running with 30*40 (== 1200) tasks. > Time: 3.190 > > I think it affects balance between pipe latency and bandwidth, while test > measures only the last. It is clear that conclusion from these numbers > depends on what do we want to have. > I don't really care on this point, I'm only testing default values, or more precisely, whatever developers though default values would be good. Btw, you are testing 3 differents configuration. Different results are expected. What worries me more is the rather the huge instability on the *same* configuration, say on a pipe/thread/70 groups/600 iterations run, where results range from 2.7s[0] to 7.4s, or a socket/thread/20 groups/1400 iterations run, where results range from 2.4s to 4.5s. - Arnaud [0]: numbers extracted from a recent run of 9.0-RELEASE on a Xeon E5-1650 platform. From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 10 19:13:47 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F13E5106564A; Tue, 10 Apr 2012 19:13:47 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id D57CD8FC08; Tue, 10 Apr 2012 19:13:46 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so138770bkc.13 for ; Tue, 10 Apr 2012 12:13:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8ZWDssOPUTIzmiGTu/VNGj/gU8fSY+gG7N3Vg9PLcuo=; b=yTcvgifT7Hagq6FIPBUvAQuzSyDeae1MNXHhywmB96czUClyI41D0Neau65R1lOW/t bxF1eKoypAzIm3xBayCZvpoWEz2klHMfh9qy1rMyyZSmlxfbm92cAw3NSqo+00j+S4uR DMTQ6PSp1pNRQgHzE0X38zjPnF+FrO9MxQclY9DB7WXKto8J0pPO+v53htFMH21JSBMQ tu/eBTI2PErQthzzmcmsgJQxMOYsh/iocjGi3Xcc7z93vSUzMGnTsvqQDJxTtSlAX2Ck qVfPb1CCm+HKpG593FY2QoV8/SYbBwhEMDNJMq5uh1yI/PdmZNaWijogd4Z7uVJCVWLU LKYw== Received: by 10.204.156.216 with SMTP id y24mr5154693bkw.60.1334085225856; Tue, 10 Apr 2012 12:13:45 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id c4sm408768bkh.0.2012.04.10.12.13.43 (version=SSLv3 cipher=OTHER); Tue, 10 Apr 2012 12:13:44 -0700 (PDT) Sender: Alexander Motin Message-ID: <4F848666.8030308@FreeBSD.org> Date: Tue, 10 Apr 2012 22:13:42 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120226 Thunderbird/10.0.2 MIME-Version: 1.0 To: Arnaud Lacombe References: <4F2F7B7F.40508@FreeBSD.org> <4F366E8F.9060207@FreeBSD.org> <4F367965.6000602@FreeBSD.org> <4F396B24.5090602@FreeBSD.org> <4F3978BC.6090608@FreeBSD.org> <4F3990EA.1080002@FreeBSD.org> <4F3C0BB9.6050101@FreeBSD.org> <4F3E807A.60103@FreeBSD.org> <4F3E8858.4000001@FreeBSD.org> <4F7DE863.6080607@FreeBSD.org> <4F833F3D.7070106@FreeBSD.org> <4F846B74.9080504@FreeBSD.org> <4F8473B7.9080000@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Florian Smeets , Jeff Roberson , Andriy Gapon , FreeBSD current Subject: Re: [RFT][patch] Scheduling for HTT and not only X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 19:13:48 -0000 On 04/10/12 21:46, Arnaud Lacombe wrote: > On Tue, Apr 10, 2012 at 1:53 PM, Alexander Motin wrote: >> On 04/10/12 20:18, Alexander Motin wrote: >>> On 04/10/12 19:58, Arnaud Lacombe wrote: >>>> 2012/4/9 Alexander Motin: >>>>> I have strong feeling that while this test may be interesting for >>>>> profiling, >>>>> it's own results in first place depend not from how fast scheduler >>>>> is, but >>>>> from the pipes capacity and other alike things. Can somebody hint me >>>>> what >>>>> except pipe capacity and context switch to unblocked receiver prevents >>>>> sender from sending all data in batch and then receiver from >>>>> receiving them >>>>> all in batch? If different OSes have different policies there, I think >>>>> results could be incomparable. >>>>> >>>> Let me disagree on your conclusion. If OS A does a task in X seconds, >>>> and OS B does the same task in Y seconds, if Y> X, then OS B is just >>>> not performing good enough. Internal implementation's difference for >>>> the task can not be waived as an excuse for result's comparability. >>> >>> >>> Sure, numbers are always numbers, but the question is what are they >>> showing? Understanding of the test results is even more important for >>> purely synthetic tests like this. Especially when one test run gives 25 >>> seconds, while another gives 50. This test is not completely clear to me >>> and that is what I've told. >> >> Small illustration to my point. Simple scheduler tuning affects thread >> preemption policy and changes this test results in three times: >> >> mav@test:/test/hackbench# ./hackbench 30 process 1000 >> Running with 30*40 (== 1200) tasks. >> Time: 9.568 >> >> mav@test:/test/hackbench# sysctl kern.sched.interact=0 >> kern.sched.interact: 30 -> 0 >> mav@test:/test/hackbench# ./hackbench 30 process 1000 >> Running with 30*40 (== 1200) tasks. >> Time: 5.163 >> >> mav@test:/test/hackbench# sysctl kern.sched.interact=100 >> kern.sched.interact: 0 -> 100 >> mav@test:/test/hackbench# ./hackbench 30 process 1000 >> Running with 30*40 (== 1200) tasks. >> Time: 3.190 >> >> I think it affects balance between pipe latency and bandwidth, while test >> measures only the last. It is clear that conclusion from these numbers >> depends on what do we want to have. >> > I don't really care on this point, I'm only testing default values, or > more precisely, whatever developers though default values would be > good. > > Btw, you are testing 3 differents configuration. Different results are > expected. What worries me more is the rather the huge instability on > the *same* configuration, say on a pipe/thread/70 groups/600 > iterations run, where results range from 2.7s[0] to 7.4s, or a > socket/thread/20 groups/1400 iterations run, where results range from > 2.4s to 4.5s. Due to reason I've pointed in my first message this test is _extremely_ sensitive to context switch interval. The more aggressive scheduler switches threads, the smaller will be pipe latency, but the smaller will be also bandwidth. During test run scheduler all the time recalculates interactivity index for each thread, trying to balance between latency and switching overhead. With hundreds of threads running simultaneously and interfering with each other it is quite unpredictable process. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 10 20:05:24 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A8C0C1065670 for ; Tue, 10 Apr 2012 20:05:24 +0000 (UTC) (envelope-from mwm@mired.org) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 53EC58FC0C for ; Tue, 10 Apr 2012 20:05:24 +0000 (UTC) Received: by iahk25 with SMTP id k25so266740iah.13 for ; Tue, 10 Apr 2012 13:05:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:organization :x-mailer:face:mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=c1x0YgCC9SRzIEJq0sU+SsWXLQjoj61Q/AdaghdsQcU=; b=YwUHIdSIso6blsTSTcsQihd8iVl+9zoZEGbdcMeBb7c7k/iOg+Jvo2SRadd2P84rxC Z+wfKORQjuxEacB/6TF7Yii06UmB5dX8ca8BFeJVXxcm5NPM0cUIatZSVl+ORFu3KQKB dSOR6glsnTVzptwyKoMOe3N6CwYUzwfwbllaihKlRkwWP+DGO7SoMY4SmtyKbQNPGMY7 fXXZAO2hcBKeNCnT6U/q01SMh6iJiDLpAfR0rI+xzfOUE2dF//QSG7p3ZuyKmDn9g/tJ l34IygXUQNT1w08hzlcPgLx1Md/VQZsf4EIX+dqbrDG3zbmY6QLkKSyqALXQbuRIh3BK u/pg== Received: by 10.50.192.228 with SMTP id hj4mr3614920igc.72.1334088318647; Tue, 10 Apr 2012 13:05:18 -0700 (PDT) Received: from bhuda.mired.org (74-140-201-117.dhcp.insightbb.com. [74.140.201.117]) by mx.google.com with ESMTPS id re5sm21753553igb.0.2012.04.10.13.05.17 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Apr 2012 13:05:18 -0700 (PDT) Date: Tue, 10 Apr 2012 16:05:13 -0400 From: Mike Meyer To: freebsd-hackers@freebsd.org Message-ID: <20120410160513.0b322f68@bhuda.mired.org> In-Reply-To: References: <4F2F7B7F.40508@FreeBSD.org> <4F366E8F.9060207@FreeBSD.org> <4F367965.6000602@FreeBSD.org> <4F396B24.5090602@FreeBSD.org> <4F3978BC.6090608@FreeBSD.org> <4F3990EA.1080002@FreeBSD.org> <4F3C0BB9.6050101@FreeBSD.org> <4F3E807A.60103@FreeBSD.org> <4F3E8858.4000001@FreeBSD.org> <4F7DE863.6080607@FreeBSD.org> <4F833F3D.7070106@FreeBSD.org> Organization: Meyer Consulting X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd8.2) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAG1BMVEXguIzRkGnhyaz069mXhW0WHRnbrnR9WCQ6LB0CchNMAAACSUlEQVQ4jV2TQW7jMAxFGaPQOgQEdZaGMsgBrAvUA03dCxj1Uu4U2gfwQD7AGNax51NK07RcxXz6/CSl0Ij450vkPG1jzpIZM1UwDCl/xB14TWnNX8A00Qj5a0mnVFVbVUz4MeErea2HikSRqZzY894zwg9p2+/AtO8LzxFED+tNAUFeU29iFOLRxlZAcdo9A8wi8ZBMV4BKPde82Oxrvs6BTkulQIClte0DLFzzsKk9j1MBex8iUaP00Bd78S/muyFScrTXz6zLkEUxJp+SabQfNOs4f4Jpx5qSZ/304PWwlEWP1cOn/mJQR7EOD+uKhjcBLziuL7xoY5Xm+VFAUSw/LwwwsHEHxihpwV4EJH0xXRkbw1PkRw+X4pEuSJwBggqk+HEYKkiL5/74/nQkogigzQsAFrakxZyfw3wMIEEZPv4AWMfxwqE5GNxGaERjmH+PG8AE0L4/w9g0lsp1raLYAN5azQa+AOoO9NwcpFkTrG2VKNMNEL5UKUUAw34tha0z7onUG0oBoNtczE04GwFE3wCHc0ChezAJ6A1WMV81AtY7wDAJSlXwV+4cwBvsOsrQMRawfQEBz0deEZ7WNpV2szckIKo5VpDHDSDvF1GItwqqAlG01Hh50BGtVhuUkjkasg/14bYFGCgWg1fSWHvmOoJck2xdp9ZvZBHzDVTzX23TkrOn7qe5U2COEw5D4Vx3qEQpFY2Z/3QFnJxzp7YCmSMG19nOUoe869zZfOQb5ywQuWu0yCn5+8gxZz+BE7vG3j4/wbf4D/sXN9Wug1s7AAAAAElFTkSuQmCC Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQng007War6WgxQXMJq0pxKUFQWvuuQSwHjaoGne8bSueu2bV8PvpuutSIqhROT5JTqzRp17 Subject: Re: [RFT][patch] Scheduling for HTT and not only X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 20:05:24 -0000 On Tue, 10 Apr 2012 12:58:00 -0400 Arnaud Lacombe wrote: > Let me disagree on your conclusion. If OS A does a task in X seconds, > and OS B does the same task in Y seconds, if Y > X, then OS B is just > not performing good enough. Others have pointed out one problem with this statement. Let me point out another: It ignores the purpose of the system. If you change the task to doing N concurrent versions of the task, and OS A time increases linearly with the number of tasks (say it's time X*N) but OS B stair-steps at the number of processors in the system (i.e. Y*floor(N/P)), then OS A is just not performing good enough. A more concrete example: if OS B spends a couple of microseconds optimizing disk access order and OS A doesn't, then a single process writing to disk on OS A could well run faster than the same on OS B. However, the maximum throughput on OS B as you add process will be higher than it is on OS A. Which one you want will depend on what you're using the system for. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 10 20:50:40 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A40D51065672 for ; Tue, 10 Apr 2012 20:50:40 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 29A118FC0A for ; Tue, 10 Apr 2012 20:50:40 +0000 (UTC) Received: by wern13 with SMTP id n13so182103wer.13 for ; Tue, 10 Apr 2012 13:50:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3Mx9yRLC5GYdE1EmQw4gUfpEQB14yRqBQ7oHyzJh7l4=; b=JDEsjtZM2fvUIczDxNIHNjAXtJ7iVWtkfdZBr1iedCo4cO/FapeU/GaGHMFwhvX/vc 2ROQkEDZfTnzVPeHDPl/JlgzQHpJRZUjFx4RVvSkoGm+opVkw+FanVgBTPo6OzKyqJL5 UA1wmWpLnqfLb4pePL/v+1SXjyCITgz1FKz+Kf7rv/br6eAR424c9/g6mwBmlHUGCHTw Ys27u8Z97NzBBOqpb8jNHb6cmtix10MQNQTngTeZpRCLSKuxEjIqOrgmww0wfBleWozT NjEd//e2pIlJNt5/9UN1bdR7XAYpZH5E1EECMq18pduCwebGv6/ii6H5aciR9KSi/0PE ifNg== MIME-Version: 1.0 Received: by 10.180.79.135 with SMTP id j7mr523658wix.19.1334091039244; Tue, 10 Apr 2012 13:50:39 -0700 (PDT) Received: by 10.216.49.81 with HTTP; Tue, 10 Apr 2012 13:50:39 -0700 (PDT) In-Reply-To: <20120410160513.0b322f68@bhuda.mired.org> References: <4F2F7B7F.40508@FreeBSD.org> <4F366E8F.9060207@FreeBSD.org> <4F367965.6000602@FreeBSD.org> <4F396B24.5090602@FreeBSD.org> <4F3978BC.6090608@FreeBSD.org> <4F3990EA.1080002@FreeBSD.org> <4F3C0BB9.6050101@FreeBSD.org> <4F3E807A.60103@FreeBSD.org> <4F3E8858.4000001@FreeBSD.org> <4F7DE863.6080607@FreeBSD.org> <4F833F3D.7070106@FreeBSD.org> <20120410160513.0b322f68@bhuda.mired.org> Date: Tue, 10 Apr 2012 16:50:39 -0400 Message-ID: From: Arnaud Lacombe To: Mike Meyer Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: [RFT][patch] Scheduling for HTT and not only X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 20:50:40 -0000 Hi, On Tue, Apr 10, 2012 at 4:05 PM, Mike Meyer wrote: > On Tue, 10 Apr 2012 12:58:00 -0400 > Arnaud Lacombe wrote: >> Let me disagree on your conclusion. If OS A does a task in X seconds, >> and OS B does the same task in Y seconds, if Y > X, then OS B is just >> not performing good enough. > > Others have pointed out one problem with this statement. Let me point > out another: > > It ignores the purpose of the system. If you change the task to doing > N concurrent versions of the task, and OS A time increases linearly > with the number of tasks (say it's time X*N) but OS B stair-steps at > the number of processors in the system (i.e. Y*floor(N/P)), then OS A > is just not performing good enough. > > A more concrete example: if OS B spends a couple of microseconds > optimizing disk access order and OS A doesn't, then a single process > writing to disk on OS A could well run faster than the same on OS > B. However, the maximum throughput on OS B as you add process will be > higher than it is on OS A. Which one you want will depend on what > you're using the system for. > You are discussing implementations in both case. If the implementation is not good enough, let's improve it, but do not discard the numbers on false claims. - Arnaud From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 10 21:19:34 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56AC1106566B for ; Tue, 10 Apr 2012 21:19:34 +0000 (UTC) (envelope-from mwm@mired.org) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id E81728FC08 for ; Tue, 10 Apr 2012 21:19:33 +0000 (UTC) Received: by iahk25 with SMTP id k25so366007iah.13 for ; Tue, 10 Apr 2012 14:19:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:x-mailer:face:mime-version:content-type :content-transfer-encoding:x-gm-message-state; bh=TlASYa5JOuKWI7FpFwyEZ25lJG4Qyz3Q/+ywQmVkuzU=; b=Q9sYC+bi8TONz2bmrxFzLX3J1jTTac4aKIH2hC4hH1Adifv7UAhCWlHxqRmDpA8QmD ddM4BTWCeByC+XGbaEo+Lp/Y895RGjLymwa1rxfcINjVu5jvBaX5Eipmj19oHfo/z6hk mSWo0PtygycgdIU9QCl2HGBHU1EbeyDrr+/2hejw43b6U+chYTqBBT/maP/Pg3zCSlw8 vwPyYJPCuqL2qIqh3dU2lTtl75/XXjrpmiwuFYaU9EQbW+bfDbX8R1jt6V3MJlqz+ccs LHaLrq27WTbpgkX8dm+clSShRpTyb9UeoNbG6HrWdYjT3WVPO2qU/c7qNDjgwB/K9rZr E5sg== Received: by 10.50.163.37 with SMTP id yf5mr235931igb.27.1334092773277; Tue, 10 Apr 2012 14:19:33 -0700 (PDT) Received: from bhuda.mired.org (74-140-201-117.dhcp.insightbb.com. [74.140.201.117]) by mx.google.com with ESMTPS id p5sm21971898igl.2.2012.04.10.14.19.31 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Apr 2012 14:19:33 -0700 (PDT) Date: Tue, 10 Apr 2012 17:19:26 -0400 From: Mike Meyer To: Arnaud Lacombe Message-ID: <20120410171926.67ece307@bhuda.mired.org> In-Reply-To: References: <4F2F7B7F.40508@FreeBSD.org> <4F366E8F.9060207@FreeBSD.org> <4F367965.6000602@FreeBSD.org> <4F396B24.5090602@FreeBSD.org> <4F3978BC.6090608@FreeBSD.org> <4F3990EA.1080002@FreeBSD.org> <4F3C0BB9.6050101@FreeBSD.org> <4F3E807A.60103@FreeBSD.org> <4F3E8858.4000001@FreeBSD.org> <4F7DE863.6080607@FreeBSD.org> <4F833F3D.7070106@FreeBSD.org> <20120410160513.0b322f68@bhuda.mired.org> Organization: Meyer Consulting X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd8.2) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAG1BMVEXguIzRkGnhyaz069mXhW0WHRnbrnR9WCQ6LB0CchNMAAACSUlEQVQ4jV2TQW7jMAxFGaPQOgQEdZaGMsgBrAvUA03dCxj1Uu4U2gfwQD7AGNax51NK07RcxXz6/CSl0Ij450vkPG1jzpIZM1UwDCl/xB14TWnNX8A00Qj5a0mnVFVbVUz4MeErea2HikSRqZzY894zwg9p2+/AtO8LzxFED+tNAUFeU29iFOLRxlZAcdo9A8wi8ZBMV4BKPde82Oxrvs6BTkulQIClte0DLFzzsKk9j1MBex8iUaP00Bd78S/muyFScrTXz6zLkEUxJp+SabQfNOs4f4Jpx5qSZ/304PWwlEWP1cOn/mJQR7EOD+uKhjcBLziuL7xoY5Xm+VFAUSw/LwwwsHEHxihpwV4EJH0xXRkbw1PkRw+X4pEuSJwBggqk+HEYKkiL5/74/nQkogigzQsAFrakxZyfw3wMIEEZPv4AWMfxwqE5GNxGaERjmH+PG8AE0L4/w9g0lsp1raLYAN5azQa+AOoO9NwcpFkTrG2VKNMNEL5UKUUAw34tha0z7onUG0oBoNtczE04GwFE3wCHc0ChezAJ6A1WMV81AtY7wDAJSlXwV+4cwBvsOsrQMRawfQEBz0deEZ7WNpV2szckIKo5VpDHDSDvF1GItwqqAlG01Hh50BGtVhuUkjkasg/14bYFGCgWg1fSWHvmOoJck2xdp9ZvZBHzDVTzX23TkrOn7qe5U2COEw5D4Vx3qEQpFY2Z/3QFnJxzp7YCmSMG19nOUoe869zZfOQb5ywQuWu0yCn5+8gxZz+BE7vG3j4/wbf4D/sXN9Wug1s7AAAAAElFTkSuQmCC Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlx1KYF6fLr2gi0s3H8eMNL3KkDIeJ0X6BFiZoyArdCYTyCrwzkenIbipgZ+wLkhnFCM7Je Cc: freebsd-hackers@freebsd.org Subject: Re: [RFT][patch] Scheduling for HTT and not only X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 21:19:34 -0000 On Tue, 10 Apr 2012 16:50:39 -0400 Arnaud Lacombe wrote: > On Tue, Apr 10, 2012 at 4:05 PM, Mike Meyer wrote: > > On Tue, 10 Apr 2012 12:58:00 -0400 > > Arnaud Lacombe wrote: > >> Let me disagree on your conclusion. If OS A does a task in X seconds, > >> and OS B does the same task in Y seconds, if Y > X, then OS B is just > >> not performing good enough. > > > > Others have pointed out one problem with this statement. Let me point > > out another: [elided] > You are discussing implementations in both case. If the implementation > is not good enough, let's improve it, but do not discard the numbers > on false claims. No, I was discussing goals. You need to know what the goals of the system are before you can declare that it's "just not performing good enough" simply because another system can perform the same task faster. That may well be true, and you can get the same performance without an adverse effect on other goals. But it may also be the case that you can't reach that higher performance goal for your task without unacceptable effects on more important goals which aren't shared by the OS that's outperforming yours. One set of numbers is merely an indication that there may be an issue that needs to be addressed. They shouldn't be discarded out of hand. But they shouldn't be used to justify changes until you've verified that the changes aren't having an adverse effect on more important goals. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 10 22:15:21 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ED8C01065670 for ; Tue, 10 Apr 2012 22:15:21 +0000 (UTC) (envelope-from feld@feld.me) Received: from feld.me (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id C250B8FC1D for ; Tue, 10 Apr 2012 22:15:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=In-Reply-To:Message-Id:From:Mime-Version:Date:References:Subject:To:Content-Type; bh=MY41VZs6Luf8DjBBYcd4NDG9WD78EP8g/8Vl+yS62NA=; b=s7+7VyL4nhhZlwbS93MrMAmLM+XLxIKXKCVpe6/cwOGutgkGXESaZ4ruzdMCQ33kwOcQX/D/7M5HEFUBkls8XzZFvbuaw5C6rxKyBgKWRamk77R6l/C+mSR9VgqumzNq; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by feld.me with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SHjLN-0009M9-3C for freebsd-hackers@freebsd.org; Tue, 10 Apr 2012 17:15:21 -0500 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpa id 1334096120-23734-23733/5/12; Tue, 10 Apr 2012 22:15:20 +0000 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-hackers@freebsd.org References: Date: Tue, 10 Apr 2012 17:15:19 -0500 Mime-Version: 1.0 From: Mark Felder Message-Id: In-Reply-To: User-Agent: Opera Mail/11.62 (FreeBSD) X-SA-Score: -1.5 Subject: Re: time stops in vmware X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 22:15:22 -0000 On Tue, 10 Apr 2012 03:04:10 -0500, Daniel Braniss wrote: > no, I can't recreate it, could you? We haven't seen this problem since FreeBSD 6.x. I can't recall how reproducible it was. From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 11 01:34:50 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 35008106564A for ; Wed, 11 Apr 2012 01:34:50 +0000 (UTC) (envelope-from sushanth_rai@yahoo.com) Received: from nm24.bullet.mail.sp2.yahoo.com (nm24.bullet.mail.sp2.yahoo.com [98.139.91.94]) by mx1.freebsd.org (Postfix) with SMTP id 091A48FC08 for ; Wed, 11 Apr 2012 01:34:50 +0000 (UTC) Received: from [98.139.91.62] by nm24.bullet.mail.sp2.yahoo.com with NNFMP; 11 Apr 2012 01:34:44 -0000 Received: from [98.139.44.71] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 11 Apr 2012 01:33:44 -0000 Received: from [127.0.0.1] by omp1008.access.mail.sp2.yahoo.com with NNFMP; 11 Apr 2012 01:33:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 714572.31601.bm@omp1008.access.mail.sp2.yahoo.com Received: (qmail 29028 invoked by uid 60001); 11 Apr 2012 01:33:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1334108024; bh=s/bWaMJiZJkLKqq5qrrg36W4vUzRb0Q86iSNcI/URu4=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=R25NYlpVs651SHNBYSSl0EoFCK8yI5GHyuP6pcUUem95G6tfilhlbJIFSZHNle1uU6zLW0LCvFBQ54i6gdcA2OJfeSittEU3nT2GHLvlF8AVHEae4JbXI43yZF3m4PwrMz3vT7q7GJv8KSUDRbAvEQasKfZBCqOke9lPFPi7b5A= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=j5k1ohkRiP9p2w0E6pzCrUAgVekwRO74wXQH9j6VzARZiN/Hv7iEUPNdAoE0BMSdCqGx4wWrPBdK2egZ6jJr4fqwZn8bmiYLVBFcQVYxJeFiFVCPqf387xklfQ4R7ffkSxcKWW8g+8mPh+u11dYjiuAfsgxdU/9OXieucDxUHiQ=; X-YMail-OSG: pvF.c8QVM1mytRj1ps.n29r0PMyE31XCoezExfZ7CcWKMFi _KmtZom9vCvpYho7LPtDVikuso.kIeskvFzLVEO8FRBt0RZkxQ8tvBn1Y254 7sGjRsjz96_EpV.5c9UcndiRTR_P4_h5Pjt1sDpoNBapreniHSa.dJPdFaTD g1HkN3JhIm7IWyl_0MfE6I_f.YJGdT5sujg0wXEumf2gqUrcjJDex6oxrx4d TTF09tOPudZLYugTuJTy69m5j4tVtH5lhI90eznen9gEMFZCPThFkJJGO9dY jCW.1hyB6suENNR9FvQohMdXWvNBAJBvmzirbUUUVeZGVHyyR8kd05X7.Xmf DRC.pQscbPm0zRBuDXfVm_o_DMjEuwDXN7kAin8bkcviK1dWN1wMSeqEYtFl LutT877liS3k7.LLyLUR8RGJT2u_afR1sqs0Z3ICJkUsCUBoCwOzadvNt_.J up1Xm_ho- Received: from [209.119.38.67] by web180005.mail.gq1.yahoo.com via HTTP; Tue, 10 Apr 2012 18:33:44 PDT X-Mailer: YahooMailClassic/15.0.5 YahooMailWebService/0.8.117.340979 Message-ID: <1334108024.348.YahooMailClassic@web180005.mail.gq1.yahoo.com> Date: Tue, 10 Apr 2012 18:33:44 -0700 (PDT) From: Sushanth Rai To: Konstantin Belousov In-Reply-To: <20120410095726.GU2358@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: mlockall() on freebsd 7.2 + amd64 returns EAGAIN X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 01:34:50 -0000 =0A> > I don't know if that has anything to do with failure.=0A> The snippe= t of code that returns failure in vm_fault() is=0A> the following:=0A> > = =0A> > if (fs.pindex >=3D fs.object->size) {=0A> >=A0 =A0=0A> =A0=A0=A0unlo= ck_and_deallocate(&fs);=0A> >=A0 =A0 =A0=A0=A0return=0A> (KERN_PROTECTION_F= AILURE);=0A> > }=0A> > =0A> > Any help would be appreciated.=0A> =0A> This = might be a bug fixed in r191810, but I am not sure.=0A> =0A=0AI tried that = fix but it didn't work. What seems to happen is that libm is mmap'ed beyond= the size of the file. From truss o/p, I see the following:=0A=0Aopen("/lib= /libm.so.5",O_RDONLY,030577200)=09 =3D 3 (0x3)=0Afstat(3,{ mode=3D-r--r--r-= - ,inode=3D918533,size=3D115560,blksize=3D4096 }) =3D 0 (0x0)=0Aread(3,"\^?= ELF\^B\^A\^A\t\0\0\0\0\0\0\0"...,4096) =3D 4096 (0x1000)=0Ammap(0x0,1155072= ,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_NOCORE,3,0x0) =3D 34366242816 (0x80063= 4000)=0A=0ASo the size of the file is 115560 but mmap() length is 1155072. = The memory map of the file corresponding to libm as seen from running 'cat = /proc//map' is the following:=0A=0A0x800634000 0x80064c000 24 0 0xff= ffff002553eca8 r-x 108 54 0x0 COW NC vnode /lib/libm.so.5=0A0x80064c000 0x8= 0064d000 1 0 0xffffff01d79b0a20 r-x 1 0 0x3100 COW NNC vnode /lib/libm.so.5= =0A0x80064d000 0x80074c000 3 0 0xffffff002553eca8 r-x 108 54 0x0 COW NC vno= de /lib/libm.so.5=0A0x80074c000 0x80074e000 2 0 0xffffff01d79f1288 rw- 1 0 = 0x3100 COW NNC vnode /lib/libm.so.5=0A=0A=0Awhen the program tries to fault= -in all the pages as part of call to mlockall(), the following check in vm_= fault() fails when trying to fault-in 0x800651000.=0A=0Aif (fs.pindex >=3D = fs.object->size) {=0A unlock_and_deallocate(&fs);=0A return (KERN_P= ROTECTION_FAILURE);=0A}=0A=0Asince the object size corresponds to size of l= ibm and fault address is one page beyond the object size. Is this a bug ?= =0A=0AThanks,=0ASushanth=0A=0A From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 11 04:28:43 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5938C1065670 for ; Wed, 11 Apr 2012 04:28:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id CDFAE8FC14 for ; Wed, 11 Apr 2012 04:28:42 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q3B4Sb0e060389; Wed, 11 Apr 2012 07:28:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q3B4SbYn000280; Wed, 11 Apr 2012 07:28:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q3B4SbAi000279; Wed, 11 Apr 2012 07:28:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 11 Apr 2012 07:28:37 +0300 From: Konstantin Belousov To: Sushanth Rai Message-ID: <20120411042837.GD2358@deviant.kiev.zoral.com.ua> References: <20120410095726.GU2358@deviant.kiev.zoral.com.ua> <1334108024.348.YahooMailClassic@web180005.mail.gq1.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wmY+ywD75ArFSrfn" Content-Disposition: inline In-Reply-To: <1334108024.348.YahooMailClassic@web180005.mail.gq1.yahoo.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org Subject: Re: mlockall() on freebsd 7.2 + amd64 returns EAGAIN X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 04:28:43 -0000 --wmY+ywD75ArFSrfn Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 10, 2012 at 06:33:44PM -0700, Sushanth Rai wrote: >=20 > > > I don't know if that has anything to do with failure. > > The snippet of code that returns failure in vm_fault() is > > the following: > > >=20 > > > if (fs.pindex >=3D fs.object->size) { > > >=9A =9A > > =9A=9A=9Aunlock_and_deallocate(&fs); > > >=9A =9A =9A=9A=9Areturn > > (KERN_PROTECTION_FAILURE); > > > } > > >=20 > > > Any help would be appreciated. > >=20 > > This might be a bug fixed in r191810, but I am not sure. > >=20 >=20 > I tried that fix but it didn't work. What seems to happen is that libm is= mmap'ed beyond the size of the file. From truss o/p, I see the following: >=20 > open("/lib/libm.so.5",O_RDONLY,030577200) =3D 3 (0x3) > fstat(3,{ mode=3D-r--r--r-- ,inode=3D918533,size=3D115560,blksize=3D4096 = }) =3D 0 (0x0) > read(3,"\^?ELF\^B\^A\^A\t\0\0\0\0\0\0\0"...,4096) =3D 4096 (0x1000) > mmap(0x0,1155072,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_NOCORE,3,0x0) =3D 34= 366242816 (0x800634000) >=20 > So the size of the file is 115560 but mmap() length is 1155072. The memor= y map of the file corresponding to libm as seen from running 'cat /proc//map' is the following: >=20 > 0x800634000 0x80064c000 24 0 0xffffff002553eca8 r-x 108 54 0x0 COW NC vno= de /lib/libm.so.5 > 0x80064c000 0x80064d000 1 0 0xffffff01d79b0a20 r-x 1 0 0x3100 COW NNC vno= de /lib/libm.so.5 > 0x80064d000 0x80074c000 3 0 0xffffff002553eca8 r-x 108 54 0x0 COW NC vnod= e /lib/libm.so.5 > 0x80074c000 0x80074e000 2 0 0xffffff01d79f1288 rw- 1 0 0x3100 COW NNC vno= de /lib/libm.so.5 >=20 >=20 > when the program tries to fault-in all the pages as part of call to mlock= all(), the following check in vm_fault() fails when trying to fault-in 0x80= 0651000. >=20 > if (fs.pindex >=3D fs.object->size) { > unlock_and_deallocate(&fs); > return (KERN_PROTECTION_FAILURE); > } >=20 > since the object size corresponds to size of libm and fault address is on= e page beyond the object size. Is this a bug ? Then it should be fixed in r190885. Could you use something less antique, please ? --wmY+ywD75ArFSrfn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+FCHUACgkQC3+MBN1Mb4ji0QCfYZ9D9iptL5BNKYa1pyOoNYgt dpoAnR/NGj9SfNW2VrQ2d42QnIFLVJIT =Taew -----END PGP SIGNATURE----- --wmY+ywD75ArFSrfn-- From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 11 06:07:08 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F37EF1065670 for ; Wed, 11 Apr 2012 06:07:07 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6518B8FC0C for ; Wed, 11 Apr 2012 06:07:07 +0000 (UTC) Received: by lagv3 with SMTP id v3so543685lag.13 for ; Tue, 10 Apr 2012 23:07:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=c4Qz4j2XyjOk6yqaF24CciWod5hdVfmp1vAuKhsqBvQ=; b=G1rEmOwNYAGNeg9X+zPc9Lk20ThLZYIyJ0+ypuxKyHOfghSRAoMORRAat0HvbiS33N OuHWJ3moDiSF+2QMa15lXTLN5zGJoa7k0DCXextwU5plti73blexxATjiSCJOInuViCm TnQ5kxrdqXITY28zzB8TLnzl6UmT5HWo8mG35cvwPoTTYORM0fFLNXLqq+1S91sL+Lp4 bzC4UoQ8sGwrBMSt8RaLPkHyg57r+anIgLof89fLvQ2omlu3/iVuZXgs0KdV1II29X3r REATC3pNl+DrjkSE8BRcMTV9vu7UBXMNlrbPiS/1RMUIHCK036xlomnmbfft7CPin/0/ 2K2Q== Received: by 10.112.30.1 with SMTP id o1mr2367102lbh.3.1334124425428; Tue, 10 Apr 2012 23:07:05 -0700 (PDT) Received: from [10.254.254.77] (ppp109-252-212-252.pppoe.spdop.ru. [109.252.212.252]) by mx.google.com with ESMTPS id py12sm1698134lab.4.2012.04.10.23.07.03 (version=SSLv3 cipher=OTHER); Tue, 10 Apr 2012 23:07:04 -0700 (PDT) Message-ID: <4F851F87.3050206@zonov.org> Date: Wed, 11 Apr 2012 10:07:03 +0400 From: Andrey Zonov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Alan Cox References: <4F7B495D.3010402@zonov.org> <20120404071746.GJ2358@deviant.kiev.zoral.com.ua> <4F7DC037.9060803@rice.edu> <201204091126.25260.jhb@freebsd.org> <4F845D9B.10004@rice.edu> In-Reply-To: <4F845D9B.10004@rice.edu> Content-Type: multipart/mixed; boundary="------------060005080001060707000904" X-Gm-Message-State: ALoCoQkm0RxYXUJ6pM8WL91lL4n0GuDSRcRCsuWAKJA8w7L06iRh++ZVg5r9568wWNUNKv/DmOgT Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, alc@freebsd.org Subject: Re: problems with mmap() and disk caching X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 06:07:08 -0000 This is a multi-part message in MIME format. --------------060005080001060707000904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10.04.2012 20:19, Alan Cox wrote: > On 04/09/2012 10:26, John Baldwin wrote: >> On Thursday, April 05, 2012 11:54:31 am Alan Cox wrote: >>> On 04/04/2012 02:17, Konstantin Belousov wrote: >>>> On Tue, Apr 03, 2012 at 11:02:53PM +0400, Andrey Zonov wrote: >>>>> Hi, >>>>> >>>>> I open the file, then call mmap() on the whole file and get pointer, >>>>> then I work with this pointer. I expect that page should be only once >>>>> touched to get it into the memory (disk cache?), but this doesn't >>>>> work! >>>>> >>>>> I wrote the test (attached) and ran it for the 1G file generated from >>>>> /dev/random, the result is the following: >>>>> >>>>> Prepare file: >>>>> # swapoff -a >>>>> # newfs /dev/ada0b >>>>> # mount /dev/ada0b /mnt >>>>> # dd if=/dev/random of=/mnt/random-1024 bs=1m count=1024 >>>>> >>>>> Purge cache: >>>>> # umount /mnt >>>>> # mount /dev/ada0b /mnt >>>>> >>>>> Run test: >>>>> $ ./mmap /mnt/random-1024 30 >>>>> mmap: 1 pass took: 7.431046 (none: 262112; res: 32; super: >>>>> 0; other: 0) >>>>> mmap: 2 pass took: 7.356670 (none: 261648; res: 496; super: >>>>> 0; other: 0) >>>>> mmap: 3 pass took: 7.307094 (none: 260521; res: 1623; super: >>>>> 0; other: 0) >>>>> mmap: 4 pass took: 7.350239 (none: 258904; res: 3240; super: >>>>> 0; other: 0) >>>>> mmap: 5 pass took: 7.392480 (none: 257286; res: 4858; super: >>>>> 0; other: 0) >>>>> mmap: 6 pass took: 7.292069 (none: 255584; res: 6560; super: >>>>> 0; other: 0) >>>>> mmap: 7 pass took: 7.048980 (none: 251142; res: 11002; super: >>>>> 0; other: 0) >>>>> mmap: 8 pass took: 6.899387 (none: 247584; res: 14560; super: >>>>> 0; other: 0) >>>>> mmap: 9 pass took: 7.190579 (none: 242992; res: 19152; super: >>>>> 0; other: 0) >>>>> mmap: 10 pass took: 6.915482 (none: 239308; res: 22836; super: >>>>> 0; other: 0) >>>>> mmap: 11 pass took: 6.565909 (none: 232835; res: 29309; super: >>>>> 0; other: 0) >>>>> mmap: 12 pass took: 6.423945 (none: 226160; res: 35984; super: >>>>> 0; other: 0) >>>>> mmap: 13 pass took: 6.315385 (none: 208555; res: 53589; super: >>>>> 0; other: 0) >>>>> mmap: 14 pass took: 6.760780 (none: 192805; res: 69339; super: >>>>> 0; other: 0) >>>>> mmap: 15 pass took: 5.721513 (none: 174497; res: 87647; super: >>>>> 0; other: 0) >>>>> mmap: 16 pass took: 5.004424 (none: 155938; res: 106206; super: >>>>> 0; other: 0) >>>>> mmap: 17 pass took: 4.224926 (none: 135639; res: 126505; super: >>>>> 0; other: 0) >>>>> mmap: 18 pass took: 3.749608 (none: 117952; res: 144192; super: >>>>> 0; other: 0) >>>>> mmap: 19 pass took: 3.398084 (none: 99066; res: 163078; super: >>>>> 0; other: 0) >>>>> mmap: 20 pass took: 3.029557 (none: 74994; res: 187150; super: >>>>> 0; other: 0) >>>>> mmap: 21 pass took: 2.379430 (none: 55231; res: 206913; super: >>>>> 0; other: 0) >>>>> mmap: 22 pass took: 2.046521 (none: 40786; res: 221358; super: >>>>> 0; other: 0) >>>>> mmap: 23 pass took: 1.152797 (none: 30311; res: 231833; super: >>>>> 0; other: 0) >>>>> mmap: 24 pass took: 0.972617 (none: 16196; res: 245948; super: >>>>> 0; other: 0) >>>>> mmap: 25 pass took: 0.577515 (none: 8286; res: 253858; super: >>>>> 0; other: 0) >>>>> mmap: 26 pass took: 0.380738 (none: 3712; res: 258432; super: >>>>> 0; other: 0) >>>>> mmap: 27 pass took: 0.253583 (none: 1193; res: 260951; super: >>>>> 0; other: 0) >>>>> mmap: 28 pass took: 0.157508 (none: 0; res: 262144; super: >>>>> 0; other: 0) >>>>> mmap: 29 pass took: 0.156169 (none: 0; res: 262144; super: >>>>> 0; other: 0) >>>>> mmap: 30 pass took: 0.156550 (none: 0; res: 262144; super: >>>>> 0; other: 0) >>>>> >>>>> If I ran this: >>>>> $ cat /mnt/random-1024> /dev/null >>>>> before test, when result is the following: >>>>> >>>>> $ ./mmap /mnt/random-1024 5 >>>>> mmap: 1 pass took: 0.337657 (none: 0; res: 262144; super: >>>>> 0; other: 0) >>>>> mmap: 2 pass took: 0.186137 (none: 0; res: 262144; super: >>>>> 0; other: 0) >>>>> mmap: 3 pass took: 0.186132 (none: 0; res: 262144; super: >>>>> 0; other: 0) >>>>> mmap: 4 pass took: 0.186535 (none: 0; res: 262144; super: >>>>> 0; other: 0) >>>>> mmap: 5 pass took: 0.190353 (none: 0; res: 262144; super: >>>>> 0; other: 0) >>>>> >>>>> This is what I expect. But why this doesn't work without reading file >>>>> manually? >>>> Issue seems to be in some change of the behaviour of the reserv or >>>> phys allocator. I Cc:ed Alan. >>> I'm pretty sure that the behavior here hasn't significantly changed in >>> about twelve years. Otherwise, I agree with your analysis. >>> >>> On more than one occasion, I've been tempted to change: >>> >>> pmap_remove_all(mt); >>> if (mt->dirty != 0) >>> vm_page_deactivate(mt); >>> else >>> vm_page_cache(mt); >>> >>> to: >>> >>> vm_page_dontneed(mt); >>> >>> because I suspect that the current code does more harm than good. In >>> theory, it saves activations of the page daemon. However, more often >>> than not, I suspect that we are spending more on page reactivations than >>> we are saving on page daemon activations. The sequential access >>> detection heuristic is just too easily triggered. For example, I've >>> seen it triggered by demand paging of the gcc text segment. Also, I >>> think that pmap_remove_all() and especially vm_page_cache() are too >>> severe for a detection heuristic that is so easily triggered. >> Are you planning to commit this? >> > > Not yet. I did some tests with a file that was several times larger than > DRAM, and I didn't like what I saw. Initially, everything behaved as > expected, but about halfway through the test the bulk of the pages were > active. Despite the call to pmap_clear_reference() in > vm_page_dontneed(), the page daemon is finding the pages to be > referenced and reactivating them. The net result is that the time it > takes to read the file (from a relatively fast SSD) goes up by about > 12%. So, this still needs work. > Hi Alan, What do you think about attached patch? -- Andrey Zonov --------------060005080001060707000904 Content-Type: text/plain; charset=windows-1251; name="vm_fault.c.patch.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vm_fault.c.patch.txt" Index: sys/vm/vm_fault.c =================================================================== --- sys/vm/vm_fault.c (revision 233744) +++ sys/vm/vm_fault.c (working copy) @@ -114,9 +114,9 @@ static int vm_fault_additional_pages(vm_page_t, int, int, vm_page_t *, int *); static void vm_fault_prefault(pmap_t, vm_offset_t, vm_map_entry_t); -#define VM_FAULT_READ_AHEAD 8 -#define VM_FAULT_READ_BEHIND 7 -#define VM_FAULT_READ (VM_FAULT_READ_AHEAD+VM_FAULT_READ_BEHIND+1) +#define VM_FAULT_READ_AHEAD (MAXPHYS/PAGE_SIZE/2) +#define VM_FAULT_READ_BEHIND (VM_FAULT_READ_AHEAD-1) +#define VM_FAULT_READ (VM_FAULT_READ_AHEAD+VM_FAULT_READ_BEHIND+1) struct faultstate { vm_page_t m; --------------060005080001060707000904-- From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 11 08:29:12 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5013C106564A for ; Wed, 11 Apr 2012 08:29:12 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 372038FC0A for ; Wed, 11 Apr 2012 08:29:12 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id q3B8T53W094300 for ; Wed, 11 Apr 2012 01:29:06 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <4F8540D1.5070100@rawbw.com> Date: Wed, 11 Apr 2012 01:29:05 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120316 Thunderbird/10.0.3 MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: cp -R from the mounted ufs disk image hangs in DL+ vnread X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 08:29:12 -0000 I have an 82GB UFS image file (ufs-snapshot) mounted on some directory ufs-snapshot.mount. (mount /dev/`mdconfig -a -t vnode -f ufs-snapshot` ufs-snapshot.mount) Command 'cp -R ufs-snapshot.mount/usr other-dir/' hanged in the middle with DL+ status: $ ps ax | grep cp 73635 10 DL+ 0:12.19 cp -R ufs-snapshot.mount/usr other-dir/ 'top' shows it in vnread state: 73635 root 1 20 0 10084K 2672K vnread 1 0:12 0.00% cp When I ran 'ls' in the same mounted directory it hanged too with D+ status: $ ps ax | grep ls 75882 2 D+ 0:00.00 ls ufs-snapshot.mount/ What is happening? Why cp and ls hanged? I think, cp -R hanged first and later ls is waiting on some op initiated by cp -R. Somehow, cp -R managed to hang itself. How can I find out what cp is waiting on? 9.0-STABLE amd64 Yuri From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 11 14:12:05 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7D02E106564A for ; Wed, 11 Apr 2012 14:12:05 +0000 (UTC) (envelope-from rflynn@acsalaska.net) Received: from mailhub.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id 1123D8FC0C for ; Wed, 11 Apr 2012 14:12:05 +0000 (UTC) Received: from [127.0.0.1] (squeeze.lan.rachie.is-a-geek.net [192.168.2.30]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id 166FB7E844 for ; Wed, 11 Apr 2012 06:11:56 -0800 (AKDT) Message-ID: <4F859112.5070005@acsalaska.net> Date: Wed, 11 Apr 2012 16:11:30 +0200 From: Mel Flynn User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: FreeBSD Hackers Content-Type: multipart/mixed; boundary="------------050201080106010708050901" Cc: Subject: Debugging zombies: pthread_sigmask and sigwait X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 14:12:05 -0000 This is a multi-part message in MIME format. --------------050201080106010708050901 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, I'm currently stuck on a bug in Zarafa-spooler that creates zombies. and working around it by claiming that our pthread library isn't "normal" which uses standard signals rather then a signal thread. My limited understanding of these facilities is however not enough to see the actual problem here and reading of related manpages did not lead me to a solution either. A test case reproducing the problem is attached. What happens is that SIGCHLD is never received by the signal thread and the child processes turn to zombies. Signal counters never go up, not even for SIGINFO, which I added specifically to see if anything gets through at all. The signal thread shows being stuck in sigwait. It's reproducible on 8.3-PRERELEASE of a few days ago (r233768). I'm not able to test it on anything newer unfortunately, but I suspect this is a bug/linuxism in the code not in FreeBSD. Thanks in advance for any insights. -- Mel --------------050201080106010708050901 Content-Type: text/plain; charset=windows-1252; name="BSDmakefile.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="BSDmakefile.txt" PROG=spoolerbug NO_MAN=yes DEBUG_FLAGS=-g3 WARNS=6 WITH_DEBUG=yes LDFLAGS+=-pthread .include "../mk/core.mk" .include --------------050201080106010708050901 Content-Type: text/plain; charset=windows-1252; name="spoolerbug.c" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="spoolerbug.c" /* * vim: ts=4 sw=4 tw=78 noet ai fdm=marker */ #include __FBSDID("$FreeBSD$"); #include #include #include #include /* signal related */ #include /* vfork */ #include /* arc4random() */ #include #include #include /* printing */ #include #define SERVER_ITERATIONS 3 /* declarations */ void *signal_handler(void *); int running_server(void); void process_signal(int); /* globals */ pthread_t signal_thread; sigset_t signal_mask; bool bQuit = false; pid_t lastPid = 0; char *szCommand; size_t n_sigs_handled = 0; size_t n_sigs_child = 0; size_t n_sigs_info = 0; void * signal_handler(void *args __unused) { int sig; while( !bQuit && sigwait(&signal_mask, &sig) == 0 ) { n_sigs_handled++; process_signal(sig); } return NULL; } int running_server(void) { u_int32_t r, max = 10; pid_t pid, me; int i = 0; me = getpid(); warnx("[master]: Send SIGINFO to %u", (unsigned)me); do { warnx("[master]: lastPid = %u, n_sigs_handled=%zu, n_sigs_child=%zu" "n_sigs_info=%zu", (unsigned)lastPid, n_sigs_handled, n_sigs_child, n_sigs_info); pid = vfork(); if( pid < 0 ) break; if( pid == 0 ) { execl(szCommand, getprogname(), "-F", NULL); _exit(EXIT_FAILURE); } else { if( bQuit ) break; warnx("[master]: Child spawned with pid %u", (unsigned)pid); r = arc4random() % max; sleep((unsigned int)r); } } while( !bQuit && i++ < SERVER_ITERATIONS ); return (0); } void process_signal(int sig) { int stat; pid_t pid; switch(sig) { case SIGTERM: case SIGINT: bQuit = true; break; case SIGCHLD: n_sigs_child++; while( (pid = waitpid(-1, &stat, WNOHANG)) > 0) { lastPid = pid; } break; case SIGINFO: n_sigs_info++; break; default: signal(sig, SIG_IGN); break; } } int main(int argc, char *argv[]) { bool bForked = false; const char *opts = "F"; int ch, hr, rc; szCommand = argv[0]; while( (ch = getopt(argc, argv, opts)) != -1 ) { if( ch == 'F' ) bForked = true; } argc -= optind; argv += optind; if( !bForked ) { sigemptyset(&signal_mask); sigaddset(&signal_mask, SIGTERM); sigaddset(&signal_mask, SIGINT); sigaddset(&signal_mask, SIGCHLD); sigaddset(&signal_mask, SIGINFO); } daemon(1, 1); if( !bForked ) { rc = pthread_sigmask(SIG_BLOCK, &signal_mask, NULL); if( rc != 0 ) err(EXIT_FAILURE, "pthread_sigmask()"); pthread_create(&signal_thread, NULL, signal_handler, NULL); hr = running_server(); warnx("[master]: Joining signal thread"); pthread_join(signal_thread, NULL); } else { printf("Child says hello\n"); sleep(1); hr = 0; } return (hr); } --------------050201080106010708050901-- From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 11 14:26:22 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 52B8E106566B for ; Wed, 11 Apr 2012 14:26:22 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 34C818FC16 for ; Wed, 11 Apr 2012 14:26:22 +0000 (UTC) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta04.emeryville.ca.mail.comcast.net with comcast id wdXe1i0011u4NiLA4eSGVB; Wed, 11 Apr 2012 14:26:16 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta21.emeryville.ca.mail.comcast.net with comcast id weSE1i01a4NgCEG8heSF9M; Wed, 11 Apr 2012 14:26:15 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q3BEQDDd059222; Wed, 11 Apr 2012 08:26:13 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Mel Flynn In-Reply-To: <4F859112.5070005@acsalaska.net> References: <4F859112.5070005@acsalaska.net> Content-Type: text/plain; charset="us-ascii" Date: Wed, 11 Apr 2012 08:26:13 -0600 Message-ID: <1334154373.1082.110.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers Subject: Re: Debugging zombies: pthread_sigmask and sigwait X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 14:26:22 -0000 On Wed, 2012-04-11 at 16:11 +0200, Mel Flynn wrote: > Hi, > > I'm currently stuck on a bug in Zarafa-spooler that creates zombies. and > working around it by claiming that our pthread library isn't "normal" > which uses standard signals rather then a signal thread. > > My limited understanding of these facilities is however not enough to > see the actual problem here and reading of related manpages did not lead > me to a solution either. A test case reproducing the problem is attached. > > What happens is that SIGCHLD is never received by the signal thread and > the child processes turn to zombies. Signal counters never go up, not > even for SIGINFO, which I added specifically to see if anything gets > through at all. > > The signal thread shows being stuck in sigwait. It's reproducible on > 8.3-PRERELEASE of a few days ago (r233768). I'm not able to test it on > anything newer unfortunately, but I suspect this is a bug/linuxism in > the code not in FreeBSD. > > Thanks in advance for any insights. > _______________________________________________ > 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" The signal mask for a new thread is inherited from the parent thread. In your example code, the signal handling thread inherits the blocked status of the signals as set up in main(). Try adding this line to signal_handler() before it goes into its while() loop: pthread_sigmask(SIG_UNBLOCK, &signal_mask, NULL); -- Ian From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 11 14:45:13 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67B02106566C for ; Wed, 11 Apr 2012 14:45:13 +0000 (UTC) (envelope-from rflynn@acsalaska.net) Received: from mailhub.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id 333D28FC18 for ; Wed, 11 Apr 2012 14:45:13 +0000 (UTC) Received: from [127.0.0.1] (squeeze.lan.rachie.is-a-geek.net [192.168.2.30]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id E2A347E844; Wed, 11 Apr 2012 06:45:11 -0800 (AKDT) Message-ID: <4F8598DC.9010508@acsalaska.net> Date: Wed, 11 Apr 2012 16:44:44 +0200 From: Mel Flynn User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ian Lepore References: <4F859112.5070005@acsalaska.net> <1334154373.1082.110.camel@revolution.hippie.lan> In-Reply-To: <1334154373.1082.110.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers Subject: Re: Debugging zombies: pthread_sigmask and sigwait X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 14:45:13 -0000 On 4/11/2012 16:26, Ian Lepore wrote: > On Wed, 2012-04-11 at 16:11 +0200, Mel Flynn wrote: >> What happens is that SIGCHLD is never received by the signal thread and >> the child processes turn to zombies. Signal counters never go up, not >> even for SIGINFO, which I added specifically to see if anything gets >> through at all. >> >> The signal thread shows being stuck in sigwait. It's reproducible on >> 8.3-PRERELEASE of a few days ago (r233768). I'm not able to test it on >> anything newer unfortunately, but I suspect this is a bug/linuxism in >> the code not in FreeBSD. > The signal mask for a new thread is inherited from the parent thread. > In your example code, the signal handling thread inherits the blocked > status of the signals as set up in main(). Try adding this line to > signal_handler() before it goes into its while() loop: > > pthread_sigmask(SIG_UNBLOCK, &signal_mask, NULL); That doesn't change anything and is in contrast to what sigwait(2) says: The signals specified by set /should be blocked/ at the time of the call to sigwait(). I also thought about a different child touching the signal code and two processes blocked in sigwait in the original code (they fork a logger process prior to sigemptyset()), but I explicitly avoid that in the test case. -- Mel From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 11 14:47:31 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 27DA01065672 for ; Wed, 11 Apr 2012 14:47:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id B60AE8FC0A for ; Wed, 11 Apr 2012 14:47:30 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q3BEl4wl031962; Wed, 11 Apr 2012 17:47:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q3BEl4LL004098; Wed, 11 Apr 2012 17:47:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q3BEl33I004097; Wed, 11 Apr 2012 17:47:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 11 Apr 2012 17:47:03 +0300 From: Konstantin Belousov To: Ian Lepore Message-ID: <20120411144703.GM2358@deviant.kiev.zoral.com.ua> References: <4F859112.5070005@acsalaska.net> <1334154373.1082.110.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EontnEYYSB34MdTw" Content-Disposition: inline In-Reply-To: <1334154373.1082.110.camel@revolution.hippie.lan> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: FreeBSD Hackers , Mel Flynn Subject: Re: Debugging zombies: pthread_sigmask and sigwait X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 14:47:31 -0000 --EontnEYYSB34MdTw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 11, 2012 at 08:26:13AM -0600, Ian Lepore wrote: > On Wed, 2012-04-11 at 16:11 +0200, Mel Flynn wrote: > > Hi, > >=20 > > I'm currently stuck on a bug in Zarafa-spooler that creates zombies. and > > working around it by claiming that our pthread library isn't "normal" > > which uses standard signals rather then a signal thread. > >=20 > > My limited understanding of these facilities is however not enough to > > see the actual problem here and reading of related manpages did not lead > > me to a solution either. A test case reproducing the problem is attache= d. > >=20 > > What happens is that SIGCHLD is never received by the signal thread and > > the child processes turn to zombies. Signal counters never go up, not > > even for SIGINFO, which I added specifically to see if anything gets > > through at all. > >=20 > > The signal thread shows being stuck in sigwait. It's reproducible on > > 8.3-PRERELEASE of a few days ago (r233768). I'm not able to test it on > > anything newer unfortunately, but I suspect this is a bug/linuxism in > > the code not in FreeBSD. > >=20 > > Thanks in advance for any insights. > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >=20 > The signal mask for a new thread is inherited from the parent thread. > In your example code, the signal handling thread inherits the blocked > status of the signals as set up in main(). Try adding this line to > signal_handler() before it goes into its while() loop: >=20 > pthread_sigmask(SIG_UNBLOCK, &signal_mask, NULL); This is completely wrong. sigwait(2) requires the waited signals to be blocked, so the code is right in this regard. What happens, as I guess it, the SIGINFO and SIGCHLD are ignored, so kernel do not even bother to queue the signals to the master process. Register a dummy signal handler for your signals with sigaction before creating 'signal_handler' thread. --EontnEYYSB34MdTw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+FmWcACgkQC3+MBN1Mb4g21wCfe9r+dXNxfVNllIS5PYUc+Qdb ELcAn3lVshYCjbPyxtQMb/2vosmK2d8l =+hSJ -----END PGP SIGNATURE----- --EontnEYYSB34MdTw-- From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 11 15:25:30 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8EFBE1065676 for ; Wed, 11 Apr 2012 15:25:30 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by mx1.freebsd.org (Postfix) with ESMTP id 6D8CC8FC25 for ; Wed, 11 Apr 2012 15:25:30 +0000 (UTC) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta12.emeryville.ca.mail.comcast.net with comcast id wfPu1i0070FhH24ACfRQFi; Wed, 11 Apr 2012 15:25:24 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta08.emeryville.ca.mail.comcast.net with comcast id wfRN1i00Y4NgCEG8UfRPmU; Wed, 11 Apr 2012 15:25:24 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q3BFPLWH059284; Wed, 11 Apr 2012 09:25:21 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Konstantin Belousov In-Reply-To: <20120411144703.GM2358@deviant.kiev.zoral.com.ua> References: <4F859112.5070005@acsalaska.net> <1334154373.1082.110.camel@revolution.hippie.lan> <20120411144703.GM2358@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset="us-ascii" Date: Wed, 11 Apr 2012 09:25:21 -0600 Message-ID: <1334157921.1082.111.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers , Mel Flynn Subject: Re: Debugging zombies: pthread_sigmask and sigwait X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 15:25:30 -0000 On Wed, 2012-04-11 at 17:47 +0300, Konstantin Belousov wrote: > On Wed, Apr 11, 2012 at 08:26:13AM -0600, Ian Lepore wrote: > > On Wed, 2012-04-11 at 16:11 +0200, Mel Flynn wrote: > > > Hi, > > > > > > I'm currently stuck on a bug in Zarafa-spooler that creates zombies. and > > > working around it by claiming that our pthread library isn't "normal" > > > which uses standard signals rather then a signal thread. > > > > > > My limited understanding of these facilities is however not enough to > > > see the actual problem here and reading of related manpages did not lead > > > me to a solution either. A test case reproducing the problem is attached. > > > > > > What happens is that SIGCHLD is never received by the signal thread and > > > the child processes turn to zombies. Signal counters never go up, not > > > even for SIGINFO, which I added specifically to see if anything gets > > > through at all. > > > > > > The signal thread shows being stuck in sigwait. It's reproducible on > > > 8.3-PRERELEASE of a few days ago (r233768). I'm not able to test it on > > > anything newer unfortunately, but I suspect this is a bug/linuxism in > > > the code not in FreeBSD. > > > > > > Thanks in advance for any insights. > > > _______________________________________________ > > > 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" > > > > The signal mask for a new thread is inherited from the parent thread. > > In your example code, the signal handling thread inherits the blocked > > status of the signals as set up in main(). Try adding this line to > > signal_handler() before it goes into its while() loop: > > > > pthread_sigmask(SIG_UNBLOCK, &signal_mask, NULL); > > This is completely wrong. sigwait(2) requires the waited signals to be > blocked, so the code is right in this regard. > Ooops, sorry. The code that sets up our signal handling threads uses SIG_SETMASK rather than BLOCK/UNBLOCK, and my quick glance at it misinterpretted what it was doing. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 11 15:58:45 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A523C106566C for ; Wed, 11 Apr 2012 15:58:45 +0000 (UTC) (envelope-from rflynn@acsalaska.net) Received: from mailhub.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id 5BBE18FC16 for ; Wed, 11 Apr 2012 15:58:45 +0000 (UTC) Received: from [127.0.0.1] (squeeze.lan.rachie.is-a-geek.net [192.168.2.30]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id 4F6407E818; Wed, 11 Apr 2012 07:58:43 -0800 (AKDT) Message-ID: <4F85AA17.9010107@acsalaska.net> Date: Wed, 11 Apr 2012 17:58:15 +0200 From: Mel Flynn User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Konstantin Belousov References: <4F859112.5070005@acsalaska.net> <1334154373.1082.110.camel@revolution.hippie.lan> <20120411144703.GM2358@deviant.kiev.zoral.com.ua> In-Reply-To: <20120411144703.GM2358@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ian Lepore , FreeBSD Hackers Subject: Re: Debugging zombies: pthread_sigmask and sigwait X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 15:58:45 -0000 On 4/11/2012 16:47, Konstantin Belousov wrote: > What happens, as I guess it, the SIGINFO and SIGCHLD are ignored, so > kernel do not even bother to queue the signals to the master process. > Register a dummy signal handler for your signals with sigaction > before creating 'signal_handler' thread. Right on the mark. I've modified the test code accordingly and things work as expected. I've also applied the logic to the Zarafa spooler and in the logs I'm finally seeing: child: [79572] E-mail for user mel was accepted by SMTP server parent: [79565] Received signal 20 ^^^^^^^^^^^^^^^^^^ Many thanks and for the archives, the diff below sig. -- Mel diff -r 509d7301c720 spoolerbug/spoolerbug.c --- a/spoolerbug/spoolerbug.c Wed Apr 11 05:37:50 2012 -0800 +++ b/spoolerbug/spoolerbug.c Wed Apr 11 07:35:50 2012 -0800 @@ -12,6 +12,7 @@ #include /* vfork */ #include /* arc4random() */ +#include /* memset() */ #include #include @@ -25,6 +26,7 @@ void *signal_handler(void *); int running_server(void); void process_signal(int); +void signal_dummy(int); /* globals */ pthread_t signal_thread; @@ -112,6 +114,12 @@ } } +void +signal_dummy(int sig __unused) +{ + return; +} + int main(int argc, char *argv[]) { @@ -131,11 +139,19 @@ if( !bForked ) { + struct sigaction dummies; + + memset(&dummies, 0, sizeof(dummies)); sigemptyset(&signal_mask); sigaddset(&signal_mask, SIGTERM); sigaddset(&signal_mask, SIGINT); sigaddset(&signal_mask, SIGCHLD); sigaddset(&signal_mask, SIGINFO); + dummies.sa_handler = signal_dummy; + dummies.sa_mask = signal_mask; + dummies.sa_flags |= SA_NOCLDSTOP; + sigaction(SIGCHLD, &dummies, NULL); + sigaction(SIGINFO, &dummies, NULL); } daemon(1, 1); From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 11 17:21:58 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8C28106564A for ; Wed, 11 Apr 2012 17:21:58 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 733628FC12 for ; Wed, 11 Apr 2012 17:21:58 +0000 (UTC) Received: by eaaf13 with SMTP id f13so319099eaa.13 for ; Wed, 11 Apr 2012 10:21:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; bh=Ffg9i4U+TQgdLbWxREGaSAvGfK93dUyJSHQd0l7i8/c=; b=Gfa0eAp7ZC/rsQjdbSsSKfW7l5flvko7cu/a42KJU/WWIpwniVa9ihtZceczcWQgXJ gEglv2CIPwc9FPbha35uA1g49MqBm6CDIhAc7NAv9ZHMKSaQeQvuRazDRyOsM1Duzyk2 YNcrlzcaMb1hltSE+w0HzFGkYMbl3GXyXSlBRpeCGqX05FkAQbTvjCt5Wow2ZwbAtXAp rTwY8LeAQwtqDiOJWVhoMuzvBLSWYU1yVDgSPN4XQxfkOzJxYAzrxVqo/tYYeWqvcxW8 fzYPCLuLolH4uU5uKZtgeMsMclQXLNdS2uZvApyjreXVqjQWhVJCYybEWoWeBcfKDRq+ LXig== Received: by 10.213.19.196 with SMTP id c4mr1013081ebb.96.1334164917524; Wed, 11 Apr 2012 10:21:57 -0700 (PDT) Received: from ernst.jennejohn.org (p578E3BA3.dip.t-dialin.net. [87.142.59.163]) by mx.google.com with ESMTPS id y11sm15174466eem.3.2012.04.11.10.21.55 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Apr 2012 10:21:56 -0700 (PDT) Date: Wed, 11 Apr 2012 19:21:53 +0200 From: Gary Jennejohn To: Jerry Toung Message-ID: <20120411192153.5672b62c@ernst.jennejohn.org> In-Reply-To: References: <20120403193124.46ad9de9@ernst.jennejohn.org> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers Subject: Re: CAM disk I/O starvation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 17:21:59 -0000 On Tue, 3 Apr 2012 14:27:43 -0700 Jerry Toung wrote: > On 4/3/12, Gary Jennejohn wrote: > > > It would be interesting to see your patch. I always run HEAD but maybe > > I could use it as a base for my own mods/tests. > > > > Here is the patch > [patch removed] Just for the archive my bad disk performance seems to have been fixed in HEAD by svn commit r234074. Seems that all interrupts were being handled by a single CPU/core (I have 6), which resulted in abysmal interrupt handling when mutltiple disks were busy. Since this commit my disk preformance is back to normal and long lags are a thing of the past. -- Gary Jennejohn From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 11 18:09:22 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDFC41065670 for ; Wed, 11 Apr 2012 18:09:22 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id AEB7C8FC19 for ; Wed, 11 Apr 2012 18:09:22 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id q3BI9Fj9011558 for ; Wed, 11 Apr 2012 11:09:19 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <4F85C8C6.3060205@rawbw.com> Date: Wed, 11 Apr 2012 11:09:10 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120316 Thunderbird/10.0.3 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4F8540D1.5070100@rawbw.com> In-Reply-To: <4F8540D1.5070100@rawbw.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: cp -R from the mounted ufs disk image hangs in DL+ vnread X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 18:09:22 -0000 I created a PR for this: http://www.freebsd.org/cgi/query-pr.cgi?pr=166851 From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 11 22:20:17 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5DA96106566C for ; Wed, 11 Apr 2012 22:20:17 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 256D88FC19 for ; Wed, 11 Apr 2012 22:20:17 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so1906053pbc.13 for ; Wed, 11 Apr 2012 15:20:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Uc3cfRerxHMWKxtaiVXpGOaLV9Zxl3So4WGzXIvJMgI=; b=k9nfcti4Cy4LM0xyPTrC8PTH/nBfQtLbRj+BCfQhMa0X1mnZwpfVehMcyfuMzlKYVU jcxujPn2bO09X+x/LXiJk+SNwZq8ntESKVV8udK3PAwQ18CnmoYfyMWs2wT1UJSesdSb 32RIS+JneCGqWJtlNMm0X5jfdWORBGxMj3taclTxVJcMxNVR9O5SbyzK238cB2mIcFm1 mdNdXKO1RlIVP2RjxuvrMZ3xmKaW7yfftG5Y1Vs2042ijARc5SUIe6qrGXAlDaQvUo79 Sq8hL04ENl3NHaGXqZSIUI/XiQwIkqOrLs0goOiQohAAV3GO/b20KMDMerUm7vDOm2VV fSbw== MIME-Version: 1.0 Received: by 10.68.204.234 with SMTP id lb10mr1073302pbc.161.1334182811333; Wed, 11 Apr 2012 15:20:11 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.143.9.11 with HTTP; Wed, 11 Apr 2012 15:20:11 -0700 (PDT) In-Reply-To: <20120410171926.67ece307@bhuda.mired.org> References: <4F2F7B7F.40508@FreeBSD.org> <4F366E8F.9060207@FreeBSD.org> <4F367965.6000602@FreeBSD.org> <4F396B24.5090602@FreeBSD.org> <4F3978BC.6090608@FreeBSD.org> <4F3990EA.1080002@FreeBSD.org> <4F3C0BB9.6050101@FreeBSD.org> <4F3E807A.60103@FreeBSD.org> <4F3E8858.4000001@FreeBSD.org> <4F7DE863.6080607@FreeBSD.org> <4F833F3D.7070106@FreeBSD.org> <20120410160513.0b322f68@bhuda.mired.org> <20120410171926.67ece307@bhuda.mired.org> Date: Wed, 11 Apr 2012 15:20:11 -0700 X-Google-Sender-Auth: BZXyA5p6TynHXswfqsPydNdNbro Message-ID: From: Adrian Chadd To: Mike Meyer Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, Arnaud Lacombe Subject: Re: [RFT][patch] Scheduling for HTT and not only X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 22:20:17 -0000 The problem, IMHO, is none of this is in any way: * documented; * modellable by a user; * explorable by a user (eg by an easy version of schedgraph to explore things in a useful way. Arnaud raises a valid point - he's given a synthetic benchmark whose numbers are unpredictable. He's asking why. There are plenty of "complex systems interact complexly!" style answers, none of which are in any way useful to an end-user. Arnaud, have you ever used ktr/sched_graph to look at what's going on? I think it'd be a worthwhile step to begin documenting what's going on here. I'd also suggest (in a completely non-inflammatory way, so you may not be the right person to write it :-) perhaps keeping some kind of blog listing the tests you're doing and what the results of system inspection are. I think that kind of thing would be very very helpful for engineers and users who are looking to get better behaviour in their use case. This kind of thing is sorely lacking at the moment. Adrian From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 12 17:14:39 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 322C01065674 for ; Thu, 12 Apr 2012 17:14:39 +0000 (UTC) (envelope-from bvowk@ualberta.ca) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id ED5C68FC0C for ; Thu, 12 Apr 2012 17:14:38 +0000 (UTC) Received: by obqv19 with SMTP id v19so1083600obq.13 for ; Thu, 12 Apr 2012 10:14:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=QYdcXw+mt+xCdrvjp2zXQeMOuBGmz9WXNqszDxXsXsY=; b=dz62Wd57eH/TTDoaxbsrMquXzOQle0Wmk3idVDM8CNnLuOjQkXD9P/3C73SnpsmWOc 74IAPO3aejL8eZTBPS9ZqiQkKvADu90n0kW9GZWUTDjYfLMEAM8aLsoo4c+hc+Ky3ZCd bm9QxILZAxQb7ESE+/2YuNVihQv1QIGb6FYVTfKOINjEEXGWoiZbwal+9I3e5BeB0GtP y1Iw16ubZixqMg1HRhNU1q51LTEENcPz89/1+p6d2B8K/h1S8VGOxKEKK89w3+FdBi0Q U0dOL9fv2N9/2WEGEnlpXIz9ELmkLfqgPXGeBgKoxmKqC1z/J9JCvStSmQMJYK3D0CCy O45g== MIME-Version: 1.0 Received: by 10.182.31.102 with SMTP id z6mr4017620obh.78.1334250878373; Thu, 12 Apr 2012 10:14:38 -0700 (PDT) Received: by 10.60.35.1 with HTTP; Thu, 12 Apr 2012 10:14:38 -0700 (PDT) Date: Thu, 12 Apr 2012 10:14:38 -0700 Message-ID: From: Barkley Vowk To: freebsd-hardware@freebsd.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmdD8Fe1Yt9QfpEL/isO++ku71WahgucWiFr+iZS+mocvcih5OT6GzfzFpU+La4yrl3rQC+ X-Mailman-Approved-At: Thu, 12 Apr 2012 18:16:29 +0000 Cc: Subject: Highpoint 2760A / Marvell 88SE9485 SAS HBA Drivers? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 17:14:39 -0000 I've got a Highpoint 2760A card that I'd like a FreeBSD driver for, I've got a machine and disks available if someone wants to tackle that. Thanks! From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 12 18:55:33 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CFFA106564A for ; Thu, 12 Apr 2012 18:55:33 +0000 (UTC) (envelope-from maninya@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 39C9C8FC0A for ; Thu, 12 Apr 2012 18:55:33 +0000 (UTC) Received: by ggnk4 with SMTP id k4so1586463ggn.13 for ; Thu, 12 Apr 2012 11:55:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=uOPVo6TlaT0FSqcyqOf7ZIkeIDr1A/fk6odmf537Rk0=; b=N14oZBE/seC+NdBf3EhMzTgZLrPyI3Q8QLVxG2O81Wlt5WxR+iqk0/4KCWhvoMmUQ9 HnanuPTojv2LGINAr+aX2Ergkct172TJbJPpKVriZFtXc8OD946zTCJ1Roub/4Jb36Do ugFYwfVmlu78nGLhB7Qq3myi3pKMGi1/46+S78o98NovuYtXZiFSM/wYA7yvTvvSRHqs PZYrincEBJxioecMAxP52WraSHWVVSqvV8sIvGIJoOWfaw/JDVY3mQrBmWuc3zXH95mI u0IjzvPqysr4g2f3veDT0qg3byXWfFkIq6xpbiQZ+TsGwcD3nvGdCt2KPod9FESEoy9h fMuw== MIME-Version: 1.0 Received: by 10.236.77.70 with SMTP id c46mr3285934yhe.5.1334256932574; Thu, 12 Apr 2012 11:55:32 -0700 (PDT) Received: by 10.146.238.13 with HTTP; Thu, 12 Apr 2012 11:55:32 -0700 (PDT) Date: Fri, 13 Apr 2012 00:25:32 +0530 Message-ID: From: Maninya M To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: mmap segmentation fault X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 18:55:33 -0000 Hello, I want to allocate memory at a specified address location 'a' of size 'b'. I wrote code below to do it, but I'm getting a seg fault. How can I solve this? How can I get the allocated memory at the required address? int main() { unsigned int *addr,*newaddr; unsigned long a=134516736,a1; unsigned long b=3895296; unsigned long flags =6; a1=(a&0xffff0000); printf("%x\n",(void *)a); newaddr=(unsigned int *)mmap((void *)a,b,6,MAP_ANONYMOUS|MAP_FIXED,-1,0); if(newaddr==MAP_FAILED) printf("mmap failed"); else printf("sucess %x",newaddr); return 0; } Output is 8049000 Segmentation fault -- Maninya From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 12 19:37:11 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 237AF106564A for ; Thu, 12 Apr 2012 19:37:11 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id A67A28FC0A for ; Thu, 12 Apr 2012 19:37:10 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id BDEF73624BB; Thu, 12 Apr 2012 21:37:09 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id A6C942847A; Thu, 12 Apr 2012 21:37:09 +0200 (CEST) Date: Thu, 12 Apr 2012 21:37:09 +0200 From: Jilles Tjoelker To: Maninya M Message-ID: <20120412193709.GA7521@stack.nl> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org Subject: Re: mmap segmentation fault X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 19:37:11 -0000 On Fri, Apr 13, 2012 at 12:25:32AM +0530, Maninya M wrote: > I want to allocate memory at a specified address location 'a' of size 'b'. > I wrote code below to do it, but I'm getting a seg fault. How can I solve > this? > How can I get the allocated memory at the required address? > int main() > { > unsigned int *addr,*newaddr; > unsigned long a=134516736,a1; > unsigned long b=3895296; > unsigned long flags =6; > a1=(a&0xffff0000); > printf("%x\n",(void *)a); > newaddr=(unsigned int *)mmap((void *)a,b,6,MAP_ANONYMOUS|MAP_FIXED,-1,0); > if(newaddr==MAP_FAILED) > printf("mmap failed"); > else > printf("sucess %x",newaddr); > return 0; > } > Output is > 8049000 > Segmentation fault If this is i386, you're mapping onto the executable itself. If you really want to map something there, you will have to move your code somewhere else or manipulate your executable to contain a suitable memory area at the required address. Try, for example, procstat -v $$ -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 13 03:10:28 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82015106566B for ; Fri, 13 Apr 2012 03:10:28 +0000 (UTC) (envelope-from sushanth_rai@yahoo.com) Received: from nm25.bullet.mail.sp2.yahoo.com (nm25.bullet.mail.sp2.yahoo.com [98.139.91.95]) by mx1.freebsd.org (Postfix) with SMTP id 3E1B78FC12 for ; Fri, 13 Apr 2012 03:10:28 +0000 (UTC) Received: from [98.139.91.70] by nm25.bullet.mail.sp2.yahoo.com with NNFMP; 13 Apr 2012 03:10:27 -0000 Received: from [98.139.44.75] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 13 Apr 2012 03:10:27 -0000 Received: from [127.0.0.1] by omp1012.access.mail.sp2.yahoo.com with NNFMP; 13 Apr 2012 03:10:27 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 252011.53968.bm@omp1012.access.mail.sp2.yahoo.com Received: (qmail 71867 invoked by uid 60001); 13 Apr 2012 03:10:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1334286626; bh=csrdP5eV89yIXYc1G5AvAzhym+IZPfFPdMViVArUST8=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=4qZpAos6WvEeNR48N5vFVpUuzWismF0GFRbiWlG3SNlJGY2i/z2AguZ6t+ftr7mb0IrqmE60+oF3F/1i7Gm99llL5s7Pjal+GF06j8H70ydu/KS/FoMckF1qw+D0zL+h4+jP7zWJDgIl2iTP+A+nTQs+A7GeKHvqgIsffipDIvM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Pne+ZsP8eH3j+OImZqMFosZlUF5BX4wJURUXF9EQxY8pWU/MCXU936v3SabjNtkaLVtxPB55H8DuxnwpLMsNsoD1XizN5zbr/cLFPeAT4o3v32OBC1kEIlmTZz54HrBMytXnEVC39SsqLlZLxS7BjSm0qSPH3lA/0nXF+CoylCs=; X-YMail-OSG: XqNbYJwVM1n16dPg5z5v3dW7xE5UIhwoMSqPtpGmjfKjb7M A0eUco0Tn1LdfJNnac8qd_M6bauB.YjVlFWZcPqPi_d7T.raQaHd9SaRU.mv dO7R1qY.G1kh7_xJ3kMpHSHRSlq.kyI8XJ6NapC0.eefZ39yqx_LJDMRFvyH KtUaCcHeFma8.Vl.LusXhnhJMcmVBLCufHl_I5lPezRIvSFWztpa3qJCjq_P CtYEKVmETs8VVBB2TJm_Eu26T4thpRDxSmERwQCBdL2mVsq0.KMMlTp7A3_i NqUs8.uoOmhyoeEiW7szaVks2FMWzWNW2jbNYvGrZvPYmAXp8lVZphckRvfl 2X0.Ndc9NCKxLpRYKbsW_oy_1xkvtB2MlVVQPDwkyERdg3odejOFh2rkZlxH VFS2y3gmGU7V7d1xgMGlT6ccBkqd0xMnEJPqAWRGBqg0Dm6exoJNUy.jALCU XhZPRRdo- Received: from [209.119.38.67] by web180010.mail.gq1.yahoo.com via HTTP; Thu, 12 Apr 2012 20:10:26 PDT X-Mailer: YahooMailClassic/15.0.5 YahooMailWebService/0.8.117.340979 Message-ID: <1334286626.57057.YahooMailClassic@web180010.mail.gq1.yahoo.com> Date: Thu, 12 Apr 2012 20:10:26 -0700 (PDT) From: Sushanth Rai To: Konstantin Belousov In-Reply-To: <20120411042837.GD2358@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-hackers@freebsd.org Subject: Re: mlockall() on freebsd 7.2 + amd64 returns EAGAIN X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 03:10:28 -0000 > > Then it should be fixed in r190885. > Thanks. That works like a charm. mlockall() mostly works now. There is still a, issue in wiring the stacks of multithreaded program when the program uses default stack allocation scheme. Thread library allocates stack for each thread by calling mmap() and sending address and size to be mapped. The kernel adjusts the start address to sgrowsz in vm_map_stack() and maps at the adjusted address. But the subsequent wiring is done using the original address, which fails. > Could you use something less antique, please ? > I would love to but I don't have control over some of these things. Hopefully some of what we have seen recently will convince higher powers to refresh to a newer release. Thanks, Sushanth From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 13 08:12:04 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA66B1065675 for ; Fri, 13 Apr 2012 08:12:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 647278FC1A for ; Fri, 13 Apr 2012 08:12:04 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q3D8Bu43030686; Fri, 13 Apr 2012 11:11:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q3D8BuNN086847; Fri, 13 Apr 2012 11:11:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q3D8BuQh086846; Fri, 13 Apr 2012 11:11:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 13 Apr 2012 11:11:56 +0300 From: Konstantin Belousov To: Sushanth Rai Message-ID: <20120413081156.GB2358@deviant.kiev.zoral.com.ua> References: <20120411042837.GD2358@deviant.kiev.zoral.com.ua> <1334286626.57057.YahooMailClassic@web180010.mail.gq1.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="K4VW92aLFVAHIWRe" Content-Disposition: inline In-Reply-To: <1334286626.57057.YahooMailClassic@web180010.mail.gq1.yahoo.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org Subject: Re: mlockall() on freebsd 7.2 + amd64 returns EAGAIN X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 08:12:05 -0000 --K4VW92aLFVAHIWRe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 12, 2012 at 08:10:26PM -0700, Sushanth Rai wrote: > >=20 > > Then it should be fixed in r190885. > >=20 >=20 > Thanks. That works like a charm.=20 >=20 > mlockall() mostly works now. There is still a, issue in wiring the stacks= of multithreaded program when the program uses default stack allocation sc= heme. Thread library allocates stack for each thread by calling mmap() and = sending address and size to be mapped. The kernel adjusts the start address= to sgrowsz in vm_map_stack() and maps at the adjusted address. But the su= bsequent wiring is done using the original address, which fails.=20 >=20 Can you, please provide stand-alone example which demostrates the issue ? I suspect this should have not changed in HEAD. --K4VW92aLFVAHIWRe Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+H370ACgkQC3+MBN1Mb4jX8wCgzQEv8IldTpqfJaFpT7auRRk5 huAAoKAENgJTjn9PtzjPKo1Hn5JNn5kE =hAfz -----END PGP SIGNATURE----- --K4VW92aLFVAHIWRe-- From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 13 16:18:41 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7016106564A for ; Fri, 13 Apr 2012 16:18:41 +0000 (UTC) (envelope-from maheshbabu90@yahoo.co.in) Received: from nm26-vm6.bullet.mail.sg3.yahoo.com (nm26-vm6.bullet.mail.sg3.yahoo.com [106.10.151.117]) by mx1.freebsd.org (Postfix) with SMTP id ED3FE8FC08 for ; Fri, 13 Apr 2012 16:18:40 +0000 (UTC) Received: from [106.10.166.61] by nm26.bullet.mail.sg3.yahoo.com with NNFMP; 13 Apr 2012 16:18:34 -0000 Received: from [106.10.151.15] by tm18.bullet.mail.sg3.yahoo.com with NNFMP; 13 Apr 2012 16:18:34 -0000 Received: from [127.0.0.1] by omp1020.mail.sg3.yahoo.com with NNFMP; 13 Apr 2012 16:18:34 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 14226.95363.bm@omp1020.mail.sg3.yahoo.com Received: (qmail 76762 invoked by uid 60001); 13 Apr 2012 16:18:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.in; s=s1024; t=1334333913; bh=9lIjg7FY7K56V6TjryJKWGuyaqUzQUaO6m6fpWYmK2E=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=dBy4lTzVA3SewNtMXHMe7lKj+rUc5I++b4ByOan2aHVyVfY1C3ADv3Is4w1f903G9SBSPW+K4bNkmpMl5BhfuTL7mlfNNBizb0Yyy/Fy7ikcN44kXSrc4FGTxHg4TpamElQY9WN0KnjfA/pxnnVSn3FWueLG3sqtMfj/voNkPww= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=2TG9RptD5rsaOthBgyL0WzI+eFATEejVh6+mWeoZCi5H0qInYCSLea5uiIaMqbRkkUSmzEFVu1IpikfX6L0KOqRNx7QdPfYfpODUWv57wBmO6JHCxLmaBE0Y0eS9VTdq180XSdtlk/7HzZ9R6gq6v8Y1ZReIqskVkmgLN7HNynU=; X-YMail-OSG: fDhxCukVM1ke73O73IYOCIqimf_.XLWYxKcp6BhRRngZ8Vm mQ2jeiMa_iHKL2VJtVkNum5JX5nU5ZTm.R0_PX5NWrQycBiEWx7669HXmzOG 6_njSUgxPAVJl.UK7pBRlK8ekwK_Hch0dIM4X5PcSgAHZt230tZZtnKuzvBh hwVgWqm5lEuVPXU5CPxfcJqxxe3VMqmaXVZP_WtF1kicHG4S4RRNQmzx0Kb. 4tawtTssztJEWlf7iR_9EAwDt4pi90hwlN67TT3eaIS2BDb7qQDdB9s1Lc9k FHOtwJ991e5XgixXA7JewRVgswnAnzMi3hhcXhokEPAPd6O7iiiqW606NI6k uLSViI2cm7.ZflmH_O9bDcTkgT71cZd4zbNazl3Q3pB.WXulwl8mVcpNzVpE FUp.sFd_ySUFt Received: from [115.113.47.66] by web193204.mail.sg3.yahoo.com via HTTP; Sat, 14 Apr 2012 00:18:33 SGT X-Mailer: YahooMailWebService/0.8.117.340979 Message-ID: <1334333913.65753.YahooMailNeo@web193204.mail.sg3.yahoo.com> Date: Sat, 14 Apr 2012 00:18:33 +0800 (SGT) From: Mahesh Babu To: "freebsd-hackers@freebsd.org" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 13 Apr 2012 16:28:05 +0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Regarding core disable in FreeBSD 9 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mahesh Babu List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 16:18:41 -0000 How to disable a particular core in FreeBSD 9?=0AHow to enable it again?=0A From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 13 17:34:40 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 85B6A106566C; Fri, 13 Apr 2012 17:34:40 +0000 (UTC) Date: Fri, 13 Apr 2012 17:34:40 +0000 From: Alexander Best To: Mahesh Babu Message-ID: <20120413173440.GA48030@freebsd.org> References: <1334333913.65753.YahooMailNeo@web193204.mail.sg3.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1334333913.65753.YahooMailNeo@web193204.mail.sg3.yahoo.com> Cc: "freebsd-hackers@freebsd.org" Subject: Re: Regarding core disable in FreeBSD 9 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 17:34:40 -0000 On Sat Apr 14 12, Mahesh Babu wrote: > How to disable a particular core in FreeBSD 9? > How to enable it again? i don't think it's possible to do that in freebsd. what you can do is to disable SMP oder hyperthreading. alternatively you can assign a certain process to a certain core. i think there's a project to disable and enable specific cores on the fly. freebsd is pretty far behind regarding this feature. beos was able to do this anno 1998 or so afair. cheers. alex From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 13 17:43:11 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 756401065670; Fri, 13 Apr 2012 17:43:11 +0000 (UTC) (envelope-from flo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5D6898FC12; Fri, 13 Apr 2012 17:43:11 +0000 (UTC) Received: from nibbler-wlan.fritz.box (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q3DHh8jJ052156; Fri, 13 Apr 2012 17:43:10 GMT (envelope-from flo@FreeBSD.org) Message-ID: <4F8865AB.10504@FreeBSD.org> Date: Fri, 13 Apr 2012 19:43:07 +0200 From: Florian Smeets User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120410 Thunderbird/12.0 MIME-Version: 1.0 To: Alexander Best References: <1334333913.65753.YahooMailNeo@web193204.mail.sg3.yahoo.com> <20120413173440.GA48030@freebsd.org> In-Reply-To: <20120413173440.GA48030@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , Mahesh Babu Subject: Re: Regarding core disable in FreeBSD 9 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 17:43:11 -0000 On 13.04.12 19:34, Alexander Best wrote: > On Sat Apr 14 12, Mahesh Babu wrote: >> How to disable a particular core in FreeBSD 9? >> How to enable it again? > > i don't think it's possible to do that in freebsd. what you can do is to > disable SMP oder hyperthreading. alternatively you can assign a certain process > to a certain core. > > i think there's a project to disable and enable specific cores on the fly. > freebsd is pretty far behind regarding this feature. beos was able to do this > anno 1998 or so afair. > You can set the following in /boot/loader.conf hint.lapic.128.disabled=1 hint.lapic.130.disabled=1 Where 128 and 130 are IDs of cores you want to disable, you can find the IDs for your CPUs/cores in dmesg or /var/log/messages e.g. cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 16 Enabling and disabling on the fly is not possible. Florian From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 13 18:03:22 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CAD9B1065670; Fri, 13 Apr 2012 18:03:22 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email2.allantgroup.com (firebox.emsphone.com [199.67.51.15]) by mx1.freebsd.org (Postfix) with ESMTP id 6F0198FC16; Fri, 13 Apr 2012 18:03:22 +0000 (UTC) Received: from dan.emsphone.com ([199.67.51.101]) by email2.allantgroup.com (8.14.4/8.14.4) with ESMTP id q3DI3Kv5099343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Apr 2012 13:03:20 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.5/8.14.5) with ESMTP id q3DI3JVS027191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Apr 2012 13:03:20 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.5/8.14.5/Submit) id q3DI3J9d027187; Fri, 13 Apr 2012 13:03:19 -0500 (CDT) (envelope-from dan) Date: Fri, 13 Apr 2012 13:03:19 -0500 From: Dan Nelson To: Florian Smeets Message-ID: <20120413180318.GA61234@dan.emsphone.com> References: <1334333913.65753.YahooMailNeo@web193204.mail.sg3.yahoo.com> <20120413173440.GA48030@freebsd.org> <4F8865AB.10504@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F8865AB.10504@FreeBSD.org> X-OS: FreeBSD 8.2-STABLE User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.2 at email2.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (email2.allantgroup.com [172.17.19.78]); Fri, 13 Apr 2012 13:03:20 -0500 (CDT) X-Scanned-By: MIMEDefang 2.68 on 172.17.19.78 Cc: Alexander Best , Mahesh Babu , "freebsd-hackers@freebsd.org" Subject: Re: Regarding core disable in FreeBSD 9 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 18:03:22 -0000 In the last episode (Apr 13), Florian Smeets said: > On 13.04.12 19:34, Alexander Best wrote: > > On Sat Apr 14 12, Mahesh Babu wrote: > >> How to disable a particular core in FreeBSD 9? How to enable it again? > > > > i don't think it's possible to do that in freebsd. what you can do is to > > disable SMP oder hyperthreading. alternatively you can assign a certain > > process to a certain core. > > > > i think there's a project to disable and enable specific cores on the > > fly. freebsd is pretty far behind regarding this feature. beos was > > able to do this anno 1998 or so afair. > > You can set the following in /boot/loader.conf > > hint.lapic.128.disabled=1 > hint.lapic.130.disabled=1 > > Where 128 and 130 are IDs of cores you want to disable, you can find the > IDs for your CPUs/cores in > > dmesg or /var/log/messages e.g. > > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 2 > cpu2 (AP): APIC ID: 4 > cpu3 (AP): APIC ID: 16 > > Enabling and disabling on the fly is not possible. You can't completely disable a core, but you can tell the scheduler not to use it, via the cpuset command. For example, "cpuset -s 1 -l 0,1" will change the mask for cpuset 1 (the default set) to only allow cpus 0 and 1. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 13 18:37:52 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 354BF106566B for ; Fri, 13 Apr 2012 18:37:52 +0000 (UTC) (envelope-from sushanth_rai@yahoo.com) Received: from nm10.bullet.mail.sp2.yahoo.com (nm10.bullet.mail.sp2.yahoo.com [98.139.91.80]) by mx1.freebsd.org (Postfix) with SMTP id 07B708FC1D for ; Fri, 13 Apr 2012 18:37:52 +0000 (UTC) Received: from [98.139.91.62] by nm10.bullet.mail.sp2.yahoo.com with NNFMP; 13 Apr 2012 18:37:45 -0000 Received: from [98.139.44.84] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 13 Apr 2012 18:37:45 -0000 Received: from [127.0.0.1] by omp1021.access.mail.sp2.yahoo.com with NNFMP; 13 Apr 2012 18:37:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 236562.93441.bm@omp1021.access.mail.sp2.yahoo.com Received: (qmail 30481 invoked by uid 60001); 13 Apr 2012 18:37:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1334342264; bh=900KiBa/0asXU5HSU8h1mybPVHluuIebD0cGo4Lrs70=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=J3qbR6+EN/lOAj+sTvyybsJTb01ayRFK7qZr545HnAU0FwYVvmIDrU4AD5bmOox+AtZyxfbHKyX+UgXZ54ysZu8wxe9qc2U9wl/s+VZG/nGS6IosJEtRrbWMTeRzp1EtrQSJUmz1E3V1asB0mtvCAV9rxaVoaZPE3SO6BDU8Mrg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=0/LMeaRYROmRE0oq1dDjHCYB6RH2vgX1yLR1iIrO6h7lQbhuSKxACy4L5Of9d6LnZf1gCG+J2ukU2uGzFWNmwaN0kAPDOtatP7WWzNjggAxocwz3lHXMOJMRdYAkZ4VeXWdUaZUlPCnb+a9po97kcyLJjMDnreou12VWPovgcTk=; X-YMail-OSG: pOnjQxcVM1klbKFfXCl_c4dIvHTOkru327gLIu.gwyH1C3d Fo2_wJlj4YKokTRVYbGU7Q2vBOMWOV__zUlgUgLldFbauZZg6kVZy4tnJTBa Axrhcz9eUlLvX9ejTE5AOl76Jw6dOqpwf0QQagRyaWmegDa3NMbW0FFGwEmT RkDkpchaFBIGKqQTW5YD7TfoHpJp6d2ZFINKTIapG4n.JAxr6qshVvAQNAuR 9kXS8_LRN2By_V60ZGiWM75d7UmWCKTJO_w.FRvi0bg0flTAYW3Ny0c.TUtt QQZttDKpiILdthEz7C7E4zSxZuOnLDbFo9mKiFbWI9vkDsxji3D6sx4_jXm6 Usk0G7onUc8MFfi1NLxIGbPzUYpPsVF7l9d8wBEqC82ZC3YQG_N2f46rNOtq zVW_00pjmhMI.qRCsRsTaH26m5hoeboFqW4LdMLDTYyvKhoh3vQyiTI2JLkg C4ACbRZ8- Received: from [209.119.38.67] by web180006.mail.gq1.yahoo.com via HTTP; Fri, 13 Apr 2012 11:37:44 PDT X-Mailer: YahooMailClassic/15.0.5 YahooMailWebService/0.8.117.340979 Message-ID: <1334342264.8672.YahooMailClassic@web180006.mail.gq1.yahoo.com> Date: Fri, 13 Apr 2012 11:37:44 -0700 (PDT) From: Sushanth Rai To: Konstantin Belousov MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-729476438-1186198209-1334342264=:8672" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: mlockall() on freebsd 7.2 + amd64 returns EAGAIN X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 18:37:52 -0000 ---729476438-1186198209-1334342264=:8672 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I've attached the simple program that creates 5 threads. Following is the o= /p of /proc//map when this program is running. Note that I modified = =0Asys/fs/procfs/procfs_map.c to print whether a region is wired. As you ca= n see from this o/p, none of stack areas get wired. =0A=0A0x400000 0x401000= 1 0 0xffffff002d943bd0 r-x 1 0 0x1000 COW NC wired vnode /var/tmp/thread1= =0A0x500000 0x501000 1 0 0xffffff002dd13e58 rw- 2 0 0x3100 NCOW NNC wired d= efault -=0A0x501000 0x600000 255 0 0xffffff002dd13e58 rwx 2 0 0x3100 NCOW N= NC wired default -=0A0x800500000 0x800526000 38 0 0xffffff0025574000 r-x 19= 2 46 0x1004 COW NC wired vnode /libexec/ld-elf.so.1=0A0x800526000 0x8005370= 00 17 0 0xffffff002d9f81b0 rw- 1 0 0x3100 NCOW NNC wired default -=0A0x8006= 26000 0x80062d000 7 0 0xffffff002dd13bd0 rw- 1 0 0x3100 COW NNC wired vnode= /libexec/ld-elf.so.1=0A0x80062d000 0x800633000 6 0 0xffffff002dd145e8 rw- = 1 0 0x3100 NCOW NNC wired default -=0A0x800633000 0x800645000 18 0 0xffffff= 00256d71b0 r-x 63 42 0x4 COW NC wired vnode /lib/libthr.so.3=0A0x800645000 = 0x800646000 1 0 0xffffff002d975510 r-x 1 0 0x3100 COW NNC wired vnode /lib/= libthr.so.3=0A0x800646000 0x800746000 0 0 0xffffff002dc5cca8 --- 4 0 0x3100= NCOW NNC not-wired default -=0A0x800746000 0x80074a000 4 0 0xffffff002572a= 288 rw- 1 0 0x3100 COW NNC wired vnode /lib/libthr.so.3=0A0x80074a000 0x800= 74c000 2 0 0xffffff002dc5cca8 rw- 4 0 0x3100 NCOW NNC wired default -=0A0x8= 0074c000 0x80083e000 242 0 0xffffff001cd226c0 r-x 238 92 0x1004 COW NC wire= d vnode /lib/libc.so.7=0A0x80083e000 0x80083f000 1 0 0xffffff002dd12000 r-x= 1 0 0x3100 COW NNC wired vnode /lib/libc.so.7=0A0x80083f000 0x80093e000 0 = 0 0xffffff002dc5cca8 --- 4 0 0x3100 NCOW NNC not-wired default -=0A0x80093e= 000 0x80095d000 31 0 0xffffff002dddc360 rw- 1 0 0x3100 COW NNC wired vnode = /lib/libc.so.7=0A0x80095d000 0x800974000 23 0 0xffffff002dc5cca8 rw- 4 0 0x= 3100 NCOW NNC wired default -=0A0x800a00000 0x800b00000 256 0 0xffffff002db= d1798 rw- 1 0 0x3100 NCOW NNC wired default -=0A0x800b00000 0x800c00000 256= 0 0xffffff002dd14948 rw- 1 0 0x3100 NCOW NNC wired default -=0A0x7fffff3db= 000 0x7fffff3fb000 1 0 0xffffff002dbb4360 rw- 1 0 0x3100 NCOW NNC not-wired= default -=0A0x7fffff5dc000 0x7fffff5fc000 1 0 0xffffff002dc66af8 rw- 1 0 0= x3100 NCOW NNC not-wired default -=0A0x7fffff7dd000 0x7fffff7fd000 1 0 0xff= ffff002dbea438 rw- 1 0 0x3100 NCOW NNC not-wired default -=0A0x7fffff9de000= 0x7fffff9fe000 1 0 0xffffff002dd7fd80 rw- 1 0 0x3100 NCOW NNC not-wired de= fault -=0A0x7fffffbdf000 0x7fffffbff000 1 0 0xffffff002dbe9438 rw- 1 0 0x31= 00 NCOW NNC not-wired default -=0A0x7fffffbff000 0x7fffffc00000 0 0 0 --- 0= 0 0x0 NCOW NNC not-wired none -=0A0x7ffffffe0000 0x800000000000 32 0 0xfff= fff002dd125e8 rwx 1 0 0x3100 NCOW NNC wired default -=0A=0A--- On Fri, 4/13= /12, Konstantin Belousov wrote:=0A=0A> From: Konstant= in Belousov =0A> Subject: Re: mlockall() on freebsd 7.= 2 + amd64 returns EAGAIN=0A> To: "Sushanth Rai" =0A= > Cc: freebsd-hackers@freebsd.org=0A> Date: Friday, April 13, 2012, 1:11 AM= =0A> On Thu, Apr 12, 2012 at 08:10:26PM=0A> -0700, Sushanth Rai wrote:=0A> = > > =0A> > > Then it should be fixed in r190885.=0A> > > =0A> > =0A> > Than= ks. That works like a charm. =0A> > =0A> > mlockall() mostly works now. The= re is still a, issue in=0A> wiring the stacks of multithreaded program when= the program=0A> uses default stack allocation scheme. Thread library=0A> a= llocates stack for each thread by calling mmap() and=0A> sending address an= d size to be mapped. The kernel adjusts=0A> the start address to sgrowsz in= =A0 vm_map_stack() and=0A> maps at the adjusted address. But the subsequent= wiring is=0A> done using the original address, which fails. =0A> > =0A> Ca= n you, please provide stand-alone example which=0A> demostrates the issue ?= =0A> I suspect this should have not changed in HEAD.=0A> ---729476438-1186198209-1334342264=:8672-- From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 13 18:46:29 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9D09F106564A for ; Fri, 13 Apr 2012 18:46:29 +0000 (UTC) (envelope-from sushanth_rai@yahoo.com) Received: from nm23.bullet.mail.sp2.yahoo.com (nm23.bullet.mail.sp2.yahoo.com [98.139.91.93]) by mx1.freebsd.org (Postfix) with SMTP id 7261C8FC0C for ; Fri, 13 Apr 2012 18:46:29 +0000 (UTC) Received: from [98.139.91.70] by nm23.bullet.mail.sp2.yahoo.com with NNFMP; 13 Apr 2012 18:46:29 -0000 Received: from [98.139.44.76] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 13 Apr 2012 18:46:29 -0000 Received: from [127.0.0.1] by omp1013.access.mail.sp2.yahoo.com with NNFMP; 13 Apr 2012 18:46:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 115453.98679.bm@omp1013.access.mail.sp2.yahoo.com Received: (qmail 45264 invoked by uid 60001); 13 Apr 2012 18:46:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1334342788; bh=e6xD1Co+A/wKh/hLX01q92at8lrdxSj4xkwJFj9iGtE=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=nacgbyxz7LoZ3U0nGT+9LiQ/B30aG5a1xMP6Nk38pbfI8ugkXfMkQQgpOxwZ70wFSrRLodiDsJRNFnhEm083Sv0E8tvCpzi+F6nBLNYvExmg9+Zuudz0UTqhrC7tGHHq1ZkYyx98y47s4CQnwrHM3g95CPQLT6HCK8rjk39jQBk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=T4eqHdflkuxt27u7T2c4GIdqbV9UeYcShwajIAXyk0bN1cpib8OHqO+D2brOjzmD2eGwN4DE6LpR1OhTGjYJVN2kzy9Grm0JYP4BUdzk7wVXA51heXDIvbZN4HKCucgE7CFxzeYJWTNC25NEri/HNKXXtljgdvwQxeURMoCr9A4=; X-YMail-OSG: 2oECJfYVM1kF7VhhoQuQ_6cm0T97GethdSEY1OEj9z7Ucug IrSSIwYi_Lf6e5idk2uMzDnPtewSfC6qqSC54bFtmennJilK7u.vLlcFCGGv 4I9pIE5ZA_vuqDPGfTFTLHsm1.mqO8oJg9JNVKV0yb4luH2gSSqlBjtchkwi Vdro6IOEw3MNr1zuuB57K7PWsqvOXLoOil6WePmah6pbJUcKEnBBMl6UAlyL kGjuhpJXd6gtS0JhnvVQ.fxk1_4_tvUmer7tO2Za2T3dsZ30Wg779m5aUzuN 1cq398jeE4XFHbpCGR8V2LQQdPQpf2hDdsOkpEauW1nY1XpwqFwP8y0nWakG lNzuI_ohi5WUFUv_a8XTH1hiwamtqXZmugsEcyp1T5kOOtNCKXgDgX5BADRe lKzogUlAuGN2hWsa7vUQjDdsUZ1qmpTO1iuMcoxf0VCaqADOouBVFKv8uFYt cQ0369RM- Received: from [209.119.38.67] by web180002.mail.gq1.yahoo.com via HTTP; Fri, 13 Apr 2012 11:46:28 PDT X-Mailer: YahooMailClassic/15.0.5 YahooMailWebService/0.8.117.340979 Message-ID: <1334342788.95842.YahooMailClassic@web180002.mail.gq1.yahoo.com> Date: Fri, 13 Apr 2012 11:46:28 -0700 (PDT) From: Sushanth Rai To: Konstantin Belousov In-Reply-To: <1334342264.8672.YahooMailClassic@web180006.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: mlockall() on freebsd 7.2 + amd64 returns EAGAIN X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 18:46:29 -0000 Just in case the attachment doesn't come through. Here is the program:=0A= =0A#include =0A#include =0A#include =0A#inc= lude =0A#include =0A#include =0A#include = =0A#include =0A#include =0A=0Avoid * thr_fun= c(void *);=0A#define MAX_THREADS 5=0A=0Amain()=0A{=0A int i;=0A = int thread_num[MAX_THREADS];=0A pthread_t tid[MAX_THREADS];=0A=0A= if (mlockall(MCL_CURRENT|MCL_FUTURE) < 0) {=0A perro= r("Failure to lock address space");=0A exit(1);=0A }= =0A=0A for (i=3D0; i < MAX_THREADS; i++) {=0A thread_= num[i] =3D i+1;=0A if (pthread_create(&tid[i], NULL, thr_fun= c,=0A &thread_num[i]) !=3D 0) {=0A = perror("thread creation failed");=0A = exit(1);=0A }=0A }=0A=0A for (i=3D0; i < M= AX_THREADS; i++) {=0A if (pthread_join(tid[i], NULL) !=3D 0)= {=0A perror("pthread_join failed\n");=0A = exit(1);=0A }=0A }=0A}=0A=0Avoid * thr_f= unc(void *arg)=0A{=0A int *tnum =3D (int *)arg;=0A printf("Thea= d %d going to sleep\n", *tnum);=0A=0A while(1) {=0A sl= eep(5);=0A } =0A}=0A=0A=0A--- On Fri, 4/13/12, Sushanth Rai <= sushanth_rai@yahoo.com> wrote:=0A=0A> From: Sushanth Rai =0A> Subject: Re: mlockall() on freebsd 7.2 + amd64 returns EAGAIN=0A= > To: "Konstantin Belousov" =0A> Cc: freebsd-hackers@f= reebsd.org=0A> Date: Friday, April 13, 2012, 11:37 AM=0A> I've attached the= simple program that=0A> creates 5 threads. Following is the o/p of=0A> /pr= oc//map when this program is running. Note=0A> that I modified =0A> sy= s/fs/procfs/procfs_map.c to print whether a region is=0A> wired. As you can= see from this o/p, none of stack areas get=0A> wired. =0A> =0A> 0x400000 0= x401000 1 0 0xffffff002d943bd0 r-x 1 0 0x1000 COW=0A> NC wired vnode /var/t= mp/thread1=0A> 0x500000 0x501000 1 0 0xffffff002dd13e58 rw- 2 0 0x3100 NCOW= =0A> NNC wired default -=0A> 0x501000 0x600000 255 0 0xffffff002dd13e58 rwx= 2 0 0x3100=0A> NCOW NNC wired default -=0A> 0x800500000 0x800526000 38 0 0= xffffff0025574000 r-x 192 46=0A> 0x1004 COW NC wired vnode /libexec/ld-elf.= so.1=0A> 0x800526000 0x800537000 17 0 0xffffff002d9f81b0 rw- 1 0=0A> 0x3100= NCOW NNC wired default -=0A> 0x800626000 0x80062d000 7 0 0xffffff002dd13bd= 0 rw- 1 0=0A> 0x3100 COW NNC wired vnode /libexec/ld-elf.so.1=0A> 0x80062d0= 00 0x800633000 6 0 0xffffff002dd145e8 rw- 1 0=0A> 0x3100 NCOW NNC wired def= ault -=0A> 0x800633000 0x800645000 18 0 0xffffff00256d71b0 r-x 63 42=0A> 0x= 4 COW NC wired vnode /lib/libthr.so.3=0A> 0x800645000 0x800646000 1 0 0xfff= fff002d975510 r-x 1 0=0A> 0x3100 COW NNC wired vnode /lib/libthr.so.3=0A> 0= x800646000 0x800746000 0 0 0xffffff002dc5cca8 --- 4 0=0A> 0x3100 NCOW NNC n= ot-wired default -=0A> 0x800746000 0x80074a000 4 0 0xffffff002572a288 rw- 1= 0=0A> 0x3100 COW NNC wired vnode /lib/libthr.so.3=0A> 0x80074a000 0x80074c= 000 2 0 0xffffff002dc5cca8 rw- 4 0=0A> 0x3100 NCOW NNC wired default -=0A> = 0x80074c000 0x80083e000 242 0 0xffffff001cd226c0 r-x 238 92=0A> 0x1004 COW = NC wired vnode /lib/libc.so.7=0A> 0x80083e000 0x80083f000 1 0 0xffffff002dd= 12000 r-x 1 0=0A> 0x3100 COW NNC wired vnode /lib/libc.so.7=0A> 0x80083f000= 0x80093e000 0 0 0xffffff002dc5cca8 --- 4 0=0A> 0x3100 NCOW NNC not-wired d= efault -=0A> 0x80093e000 0x80095d000 31 0 0xffffff002dddc360 rw- 1 0=0A> 0x= 3100 COW NNC wired vnode /lib/libc.so.7=0A> 0x80095d000 0x800974000 23 0 0x= ffffff002dc5cca8 rw- 4 0=0A> 0x3100 NCOW NNC wired default -=0A> 0x800a0000= 0 0x800b00000 256 0 0xffffff002dbd1798 rw- 1 0=0A> 0x3100 NCOW NNC wired de= fault -=0A> 0x800b00000 0x800c00000 256 0 0xffffff002dd14948 rw- 1 0=0A> 0x= 3100 NCOW NNC wired default -=0A> 0x7fffff3db000 0x7fffff3fb000 1 0 0xfffff= f002dbb4360 rw- 1 0=0A> 0x3100 NCOW NNC not-wired default -=0A> 0x7fffff5dc= 000 0x7fffff5fc000 1 0 0xffffff002dc66af8 rw- 1 0=0A> 0x3100 NCOW NNC not-w= ired default -=0A> 0x7fffff7dd000 0x7fffff7fd000 1 0 0xffffff002dbea438 rw-= 1 0=0A> 0x3100 NCOW NNC not-wired default -=0A> 0x7fffff9de000 0x7fffff9fe= 000 1 0 0xffffff002dd7fd80 rw- 1 0=0A> 0x3100 NCOW NNC not-wired default -= =0A> 0x7fffffbdf000 0x7fffffbff000 1 0 0xffffff002dbe9438 rw- 1 0=0A> 0x310= 0 NCOW NNC not-wired default -=0A> 0x7fffffbff000 0x7fffffc00000 0 0 0 --- = 0 0 0x0 NCOW NNC=0A> not-wired none -=0A> 0x7ffffffe0000 0x800000000000 32 = 0 0xffffff002dd125e8 rwx 1=0A> 0 0x3100 NCOW NNC wired default -=0A> =0A> -= -- On Fri, 4/13/12, Konstantin Belousov =0A> wrote:=0A= > =0A> > From: Konstantin Belousov =0A> > Subject: Re:= mlockall() on freebsd 7.2 + amd64 returns=0A> EAGAIN=0A> > To: "Sushanth R= ai" =0A> > Cc: freebsd-hackers@freebsd.org=0A> > Da= te: Friday, April 13, 2012, 1:11 AM=0A> > On Thu, Apr 12, 2012 at 08:10:26P= M=0A> > -0700, Sushanth Rai wrote:=0A> > > > =0A> > > > Then it should be f= ixed in r190885.=0A> > > > =0A> > > =0A> > > Thanks. That works like a char= m. =0A> > > =0A> > > mlockall() mostly works now. There is still a,=0A> iss= ue in=0A> > wiring the stacks of multithreaded program when the=0A> program= =0A> > uses default stack allocation scheme. Thread library=0A> > allocates= stack for each thread by calling mmap() and=0A> > sending address and size= to be mapped. The kernel=0A> adjusts=0A> > the start address to sgrowsz in= =A0 vm_map_stack() and=0A> > maps at the adjusted address. But the subseque= nt wiring=0A> is=0A> > done using the original address, which fails. =0A> >= > =0A> > Can you, please provide stand-alone example which=0A> > demostrat= es the issue ?=0A> > I suspect this should have not changed in HEAD.=0A> >= =0A> -----Inline Attachment Follows-----=0A> =0A> _________________________= ______________________=0A> freebsd-hackers@freebsd.org=0A> mailing list=0A>= http://lists.freebsd.org/mailman/listinfo/freebsd-hackers=0A> To unsubscri= be, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 13 21:45:42 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DCC11065670; Fri, 13 Apr 2012 21:45:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id E37948FC0C; Fri, 13 Apr 2012 21:45:41 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q3DLjaw7093212; Sat, 14 Apr 2012 00:45:36 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q3DLjapt081824; Sat, 14 Apr 2012 00:45:36 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q3DLja5d081823; Sat, 14 Apr 2012 00:45:36 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 14 Apr 2012 00:45:36 +0300 From: Konstantin Belousov To: Sushanth Rai Message-ID: <20120413214536.GL2358@deviant.kiev.zoral.com.ua> References: <1334342264.8672.YahooMailClassic@web180006.mail.gq1.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p9yXrYA3ANr0wrJ4" Content-Disposition: inline In-Reply-To: <1334342264.8672.YahooMailClassic@web180006.mail.gq1.yahoo.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: alc@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: mlockall() on freebsd 7.2 + amd64 returns EAGAIN X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 21:45:42 -0000 --p9yXrYA3ANr0wrJ4 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 13, 2012 at 11:37:44AM -0700, Sushanth Rai wrote: > I've attached the simple program that creates 5 threads. Following is the= o/p of /proc//map when this program is running. Note that I modified= =20 > sys/fs/procfs/procfs_map.c to print whether a region is wired. As you can= see from this o/p, none of stack areas get wired.=20 >=20 > 0x400000 0x401000 1 0 0xffffff002d943bd0 r-x 1 0 0x1000 COW NC wired vnod= e /var/tmp/thread1 > 0x500000 0x501000 1 0 0xffffff002dd13e58 rw- 2 0 0x3100 NCOW NNC wired de= fault - > 0x501000 0x600000 255 0 0xffffff002dd13e58 rwx 2 0 0x3100 NCOW NNC wired = default - > 0x800500000 0x800526000 38 0 0xffffff0025574000 r-x 192 46 0x1004 COW NC = wired vnode /libexec/ld-elf.so.1 > 0x800526000 0x800537000 17 0 0xffffff002d9f81b0 rw- 1 0 0x3100 NCOW NNC w= ired default - > 0x800626000 0x80062d000 7 0 0xffffff002dd13bd0 rw- 1 0 0x3100 COW NNC wir= ed vnode /libexec/ld-elf.so.1 > 0x80062d000 0x800633000 6 0 0xffffff002dd145e8 rw- 1 0 0x3100 NCOW NNC wi= red default - > 0x800633000 0x800645000 18 0 0xffffff00256d71b0 r-x 63 42 0x4 COW NC wire= d vnode /lib/libthr.so.3 > 0x800645000 0x800646000 1 0 0xffffff002d975510 r-x 1 0 0x3100 COW NNC wir= ed vnode /lib/libthr.so.3 > 0x800646000 0x800746000 0 0 0xffffff002dc5cca8 --- 4 0 0x3100 NCOW NNC no= t-wired default - > 0x800746000 0x80074a000 4 0 0xffffff002572a288 rw- 1 0 0x3100 COW NNC wir= ed vnode /lib/libthr.so.3 > 0x80074a000 0x80074c000 2 0 0xffffff002dc5cca8 rw- 4 0 0x3100 NCOW NNC wi= red default - > 0x80074c000 0x80083e000 242 0 0xffffff001cd226c0 r-x 238 92 0x1004 COW NC= wired vnode /lib/libc.so.7 > 0x80083e000 0x80083f000 1 0 0xffffff002dd12000 r-x 1 0 0x3100 COW NNC wir= ed vnode /lib/libc.so.7 > 0x80083f000 0x80093e000 0 0 0xffffff002dc5cca8 --- 4 0 0x3100 NCOW NNC no= t-wired default - > 0x80093e000 0x80095d000 31 0 0xffffff002dddc360 rw- 1 0 0x3100 COW NNC wi= red vnode /lib/libc.so.7 > 0x80095d000 0x800974000 23 0 0xffffff002dc5cca8 rw- 4 0 0x3100 NCOW NNC w= ired default - > 0x800a00000 0x800b00000 256 0 0xffffff002dbd1798 rw- 1 0 0x3100 NCOW NNC = wired default - > 0x800b00000 0x800c00000 256 0 0xffffff002dd14948 rw- 1 0 0x3100 NCOW NNC = wired default - > 0x7fffff3db000 0x7fffff3fb000 1 0 0xffffff002dbb4360 rw- 1 0 0x3100 NCOW = NNC not-wired default - > 0x7fffff5dc000 0x7fffff5fc000 1 0 0xffffff002dc66af8 rw- 1 0 0x3100 NCOW = NNC not-wired default - > 0x7fffff7dd000 0x7fffff7fd000 1 0 0xffffff002dbea438 rw- 1 0 0x3100 NCOW = NNC not-wired default - > 0x7fffff9de000 0x7fffff9fe000 1 0 0xffffff002dd7fd80 rw- 1 0 0x3100 NCOW = NNC not-wired default - > 0x7fffffbdf000 0x7fffffbff000 1 0 0xffffff002dbe9438 rw- 1 0 0x3100 NCOW = NNC not-wired default - > 0x7fffffbff000 0x7fffffc00000 0 0 0 --- 0 0 0x0 NCOW NNC not-wired none - > 0x7ffffffe0000 0x800000000000 32 0 0xffffff002dd125e8 rwx 1 0 0x3100 NCOW= NNC wired default - >=20 > --- On Fri, 4/13/12, Konstantin Belousov wrote: >=20 > > From: Konstantin Belousov > > Subject: Re: mlockall() on freebsd 7.2 + amd64 returns EAGAIN > > To: "Sushanth Rai" > > Cc: freebsd-hackers@freebsd.org > > Date: Friday, April 13, 2012, 1:11 AM > > On Thu, Apr 12, 2012 at 08:10:26PM > > -0700, Sushanth Rai wrote: > > > >=20 > > > > Then it should be fixed in r190885. > > > >=20 > > >=20 > > > Thanks. That works like a charm.=20 > > >=20 > > > mlockall() mostly works now. There is still a, issue in > > wiring the stacks of multithreaded program when the program > > uses default stack allocation scheme. Thread library > > allocates stack for each thread by calling mmap() and > > sending address and size to be mapped. The kernel adjusts > > the start address to sgrowsz in=9A vm_map_stack() and > > maps at the adjusted address. But the subsequent wiring is > > done using the original address, which fails.=20 Oh, I see. The problem is the VM_MAP_WIRE_NOHOLES flag. Since we map only the initial stack fragment even for the MCL_WIREFUTURE maps, there is a hole in the stack region. In fact, for MCL_WIREFUTURE, we probably should map the whole stack at once, prefaulting all pages. Below are two patches. The change for vm_mmap.c would fix your immediate problem by allowing holes in wired region. The change for vm_map.c prefaults the whole stack instead of the initial fragment. The single-threaded programs still get a fault on stack growth. diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c index 6198629..2fd18d1 100644 --- a/sys/vm/vm_map.c +++ b/sys/vm/vm_map.c @@ -3259,7 +3259,10 @@ vm_map_stack(vm_map_t map, vm_offset_t addrbos, vm_s= ize_t max_ssize, addrbos + max_ssize < addrbos) return (KERN_NO_SPACE); =20 - init_ssize =3D (max_ssize < sgrowsiz) ? max_ssize : sgrowsiz; + if (map->flags & MAP_WIREFUTURE) + init_ssize =3D max_ssize; + else + init_ssize =3D (max_ssize < sgrowsiz) ? max_ssize : sgrowsiz; =20 PROC_LOCK(curthread->td_proc); vmemlim =3D lim_cur(curthread->td_proc, RLIMIT_VMEM); diff --git a/sys/vm/vm_mmap.c b/sys/vm/vm_mmap.c index 2588c85..3fccd9e 100644 --- a/sys/vm/vm_mmap.c +++ b/sys/vm/vm_mmap.c @@ -1561,9 +1561,11 @@ vm_mmap(vm_map_t map, vm_offset_t *addr, vm_size_t s= ize, vm_prot_t prot, * If the process has requested that all future mappings * be wired, then heed this. */ - if (map->flags & MAP_WIREFUTURE) + if (map->flags & MAP_WIREFUTURE) { vm_map_wire(map, *addr, *addr + size, - VM_MAP_WIRE_USER | VM_MAP_WIRE_NOHOLES); + VM_MAP_WIRE_USER | ((flags & MAP_STACK) ? + VM_MAP_WIRE_HOLESOK : VM_MAP_WIRE_NOHOLES)); + } } else { /* * If this mapping was accounted for in the vnode's --p9yXrYA3ANr0wrJ4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+Inn8ACgkQC3+MBN1Mb4iolQCcCiKLilWM5Ok8fuf5rSOAyQlu h/IAoOL9B0Pn/HYRABYAN0uKsOXUy+bP =QwC2 -----END PGP SIGNATURE----- --p9yXrYA3ANr0wrJ4-- From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 14 03:48:14 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C97F1065670 for ; Sat, 14 Apr 2012 03:48:14 +0000 (UTC) (envelope-from beezarliu@yahoo.com.cn) Received: from nm19-vm0.bullet.mail.bf1.yahoo.com (nm19-vm0.bullet.mail.bf1.yahoo.com [98.139.213.162]) by mx1.freebsd.org (Postfix) with SMTP id 5BD418FC12 for ; Sat, 14 Apr 2012 03:48:13 +0000 (UTC) Received: from [98.139.215.141] by nm19.bullet.mail.bf1.yahoo.com with NNFMP; 14 Apr 2012 03:48:07 -0000 Received: from [98.139.211.204] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 14 Apr 2012 03:48:07 -0000 Received: from [127.0.0.1] by smtp213.mail.bf1.yahoo.com with NNFMP; 14 Apr 2012 03:48:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.cn; s=s1024; t=1334375287; bh=I4zl2IRTXtHgkwEYgf68EFo5PUvFtbcOU/ZYCvvNY7g=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Date:From:To:Cc:References:Subject:Message-ID:X-mailer:Mime-Version:Content-Type; b=u4Lnrzb/p0b20TCtBiMhadPkJ0kjTHTWthcL6y39jpG1oj6zniytX1hURxFxghLre2OrFbqs6UhZ3nB4gOIaEXM2mGIUCStzVRcv7DoajHEQSHmKfnI8wfYYas5Wvg1jkmCdzPAvTJSPaactcAEDx93Kzd4hxCqFhiWY5riUPRU= X-Yahoo-Newman-Id: 203348.15367.bm@smtp213.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: SCczzLkVM1nsf4gC30UGCqYUTopsicAFI89BmW10KHb9ofj 8Qd.7jn3GLGBolM0PliXvIv4LTkYe68j3uxhsCnzW.sRKIJbxEkPWLoBMGVv 1cOnwMDzLr33lApMQbDEwyzL1BKDe2e7oCutRsPEn2IX0yjWFsri1cCOIlZA 7Tfp3EysKbvbfcpk1jpRiuKjHFVC6Wx4p7EJ50GZen8h8k319R9ZeAI8VFk8 louFM5blksP6AlCn8wvFRxbkSYUfjHaPQI8IK9yQa73agwHVQDSwfoEZnd_I ZoEevjdmKEew7ZbpKF3J3f8fPFSlvq.BYe3TP5TUWADXSV9CXXozzB.75E.x RzfQHsUxQ6cbfjD7yN7nMVH8AIsnVihBSNKQbQZTISBfnzpg9gIwjtMIdZgQ MHz4eZPIJIonDr4x2Vmj4iHJLmXrLtueVi9mC8goxfzOJpVWtjn7UZsgQ7ZY - X-Yahoo-SMTP: YP5UPy2swBBHZGZlvbmOrntlD3fotw-- Received: from TJ074B8XNUMBR5O (beezarliu@58.246.207.202 with login) by smtp213.mail.bf1.yahoo.com with SMTP; 13 Apr 2012 20:47:58 -0700 PDT Date: Sat, 14 Apr 2012 11:49:50 -0800 From: "beezarliu" To: "pyunyh" , "Hooman Fazaeli" References: <4E744BCE.7060302@sepehrs.com> Message-ID: <201204141149471470481@yahoo.com.cn> X-mailer: Foxmail 6, 14, 103, 24 [cn] Mime-Version: 1.0 X-Mailman-Approved-At: Sat, 14 Apr 2012 03:53:29 +0000 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: jfv , freebsd-hackers Subject: Re: Re: intel checksum offload X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 03:48:14 -0000 DQpIaSwNCkknbSBhbHNvIGN1cmlvdXMgYWJvdXQgd2h5IHRoZSBDU1VNX0lQIHdhcyByZW1vdmVk IGluIGFsbCB0aGUgaW50ZWwgTklDcy4NCkFsdGhvdWdoIHRoaXMgdGhyZWFkIGlzIHZlcnkgb2xk LCBJIHN0aWxsIG5lZWQgdGhlIGFuc3dlciBiZWNhdXNlIElQIGNoZWNrc3VtIG9mZmxvYWQgaXMg YWN0dWFsbHkgc3VwcG9ydGVkIGluIGludGVsJ3MgZGF0YXNoZWV0Lg0KDQpUaGFua3MhDQoNCjIw MTItMDQtMTQgDQoNCg0KDQpiZWV6YXJsaXUgDQoNCg0KDQq3orz+yMujuiBZb25nSHllb24gUFlV TiANCreiy83Ksbzko7ogMjAxMS0wOS0xOCAgMDQ6NTg6MTAgDQrK1bz+yMujuiBIb29tYW4gRmF6 YWVsaSANCrOty82juiBqZnY7IGZyZWVic2QtaGFja2VycyANCtb3zOKjuiBSZTogaW50ZWwgY2hl Y2tzdW0gb2ZmbG9hZCANCiANCk9uIFNhdCwgU2VwIDE3LCAyMDExIGF0IDExOjU3OjEwQU0gKzA0 MzAsIEhvb21hbiBGYXphZWxpIHdyb3RlOg0KPiBIaSBsaXN0LA0KPiANCj4gVGhlIGRhdGEgc2hl ZXQgZm9yIGludGVsIDgyNTc2IGFkdmVydGlzZXMgSVAgVFgvUlggY2hlY2tzdW0gb2ZmbG9hZA0K PiBidXQgdGhlIGRyaXZlciBkb2VzIG5vdCBzZXQgQ1NVTV9JUCBpbiBpZnAtPmlmX2h3YXNzaXN0 LiBEb2VzIHRoaXMgbWVhbiB0aGF0DQo+IGRyaXZlciAoYW5kIGNoaXApIGRvIG5vdCBzdXBwb3J0 IElQIFRYIGNoZWNrc3VtIG9mZmxvYWQgb3IgdGhlIHN1cHBvcnQgZm9yDQo+IFRYIGlzIG5vdCB5 ZXQgaW5jbHVkZWQgaW4gdGhlIGRyaXZlcj8NCkFmdGVyIHJlYWRpbmcgdGhpcyBtYWlsLCBJIGNo ZWNrZWQgZW0oNCkvbGVtKDQpIGNvZGUgYW5kIG5vdGljZWQNCnRoZXNlIGRyaXZlcnMgcmVtb3Zl ZCBDU1VNX0lQIGNhcGFiaWxpdHkgYXMgd2VsbC4gaWdiKDQpIGRpZG4ndA0Kc3VwcG9ydCBDU1VN X0lQIGZyb20gZGF5IDEgYnV0IGVtKDQpL2xlbSg0KSB1c2VkIHRvIHRha2UgYWR2YW50YWdlDQpv ZiBJUCBjaGVja3N1bSBvZmZsb2FkaW5nIGNhcGFiaWxpdHkuDQpHaXZlbiB0aGF0IHRoZXNlIGRy aXZlcnMgc2hhcmUgbWFueSBjb2RlIHdpdGggTGludXgsIEphY2sgbWF5IGtub3cNCnRoZSBkZXRh aWxzIGFuZCB3aHkgSVAgY2hlY2tzdW0gb2ZmbG9hZGluZyBjb2RlIHdhcyByZW1vdmVkLiBOb3Rl LA0KTGludXggZG9lcyBub3QgdXNlIElQIGNoZWNrc3VtIG9mZmxvYWRpbmcgc28gSSBndWVzcyB0 aGlzIGNvdWxkIGJlDQpvdmVyc2lnaHQgaW4gc2hhcmVkIGNvZGUuDQpCVFcsIGhhY2tlcnMgbWF5 IG5vdCBiZSByaWdodCBNTCB0byBwb3N0IHRoaXMga2luZCBvZiBwb3N0Lg0KQ0NlZCB0byBqZnZA LCB0aGUgZHJpdmVyIG1haW50YWluZXIuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KZnJlZWJzZC1oYWNrZXJzQGZyZWVic2Qub3JnIG1haWxpbmcgbGlz dA0KaHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWJzZC1oYWNr ZXJzDQpUbyB1bnN1YnNjcmliZSwgc2VuZCBhbnkgbWFpbCB0byAiZnJlZWJzZC1oYWNrZXJzLXVu c3Vic2NyaWJlQGZyZWVic2Qub3JnIg0K From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 14 15:38:06 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 845801065672; Sat, 14 Apr 2012 15:38:06 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6AF428FC0A; Sat, 14 Apr 2012 15:38:04 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA01007; Sat, 14 Apr 2012 18:37:57 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SJ52z-0008Ut-FB; Sat, 14 Apr 2012 18:37:57 +0300 Message-ID: <4F8999D2.1080902@FreeBSD.org> Date: Sat, 14 Apr 2012 18:37:54 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120317 Thunderbird/10.0.3 MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org, freebsd-fs@FreeBSD.org X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: Subject: [review request] zfsboot/zfsloader: support accessing filesystems within a pool X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 15:38:06 -0000 I would like to ask for a review and/or testing of the following three patches: http://people.freebsd.org/~avg/zfsboot.patches.diff These patches add support for booting from an arbitrary filesystem of any detected ZFS pool. A filesystem could be selected in zfsboot and thus will affectfrom where zfsloader would be loaded. zfsboot passes information about the boot pool and filesystem to zfsloader, which uses those for loaddev and default value of currdev. A different pool+filesystem could be selected in zfsloader for booting kernel. Also if vfs.root.mountfrom is not explicitly set and is not derived from fstab, then it gets set to the selected boot filesystem. This should could be used as a foundation for the support of Solaris-like boot environment selection. I believe that other people have already developed scripts utilizing ZFS capabilities to provide other aspects of management of boot environments. I am particularly interested in reviews of my attempt to make ZFS boot support arch-independent. The arches, of course, would have to add some code to make use of that support. Currently I only enabled it for x86. Thank you very much! -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 14 16:04:04 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B141106566B for ; Sat, 14 Apr 2012 16:04:04 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by mx1.freebsd.org (Postfix) with ESMTP id 5B1D78FC08 for ; Sat, 14 Apr 2012 16:04:04 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta15.emeryville.ca.mail.comcast.net with comcast id xs061i0031smiN4AFs2y6j; Sat, 14 Apr 2012 16:02:58 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta20.emeryville.ca.mail.comcast.net with comcast id xs2x1i00z4NgCEG8gs2yTv; Sat, 14 Apr 2012 16:02:58 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q3EG2uu8062608; Sat, 14 Apr 2012 10:02:56 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Aleksander Dutkowski In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Sat, 14 Apr 2012 10:02:56 -0600 Message-ID: <1334419376.1082.162.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-arm@freebsd.org Subject: Re: [GSoC] [ARM] arm cleanup - my own proposal X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 16:04:04 -0000 On Sun, 2012-04-01 at 20:19 +0200, Aleksander Dutkowski wrote: > hello! > > after few weeks searching for interesting idea for me, I've decided to > propose my own one. It is already mentioned on IdeasPage: > - ARM cleanup > > Why I have chosen this one? I am very interested in embedded world. > Now I am working on porting FBSD to at91sam9g45 - I will be much more > motivated working on arm fbsd project than any other. > > Why should you let me do that project? While working on freebsd/arm > I've noticed places that could be optimized, or separated, i.e. > at91_samsize() should be declared for each board separately - now, > this function has if-else and checks, which board is he running on. > > I would like to identify and fix that bugs, so the code will be more > efficient and clear. Moreover, I think there should be a > tutorial/framework for adding new boards or SoCs, so I will be > simplier. I am currently reading the code in sys/arm/at91 and > searching for improvements but I will be very pleased, if you send me > your insights. > > The first question is - should I cleanup only at91 branch or more? I > am quite familiar with at91 right now. > The second - how to test the code? Some of boards could be tested in > qemu, I could buy board with at91rm9200 for example, if I'm in. But > maybe I will find here people with their own boards, they could help > me testing? I havs sbc6045 board with at91sam9g45 SoC but it hasn't > fbsd support yet (I'm working on it now :) ) > > I also thought about reducing kernel size for embedded, if arm cleanup > won't fit. > > I'm curious whether you ever got a reply to this privately, since nothing appeared on the list? I meant to reply and offer to do testing of at91 changes on rm9200 hardware, but I was on vacation when you posted originally, and I forgot to reply until just now. It's been my growing impression for about a year that the arm support in FreeBSD has atrophied to the point where it can barely be said that it's supported at all. Now I see this morning that marius@ has committed a set of style cleanups to the at91 code (r234281), so maybe it's not quite as dead as I feared. At Symmetricom we build a variety of products based on the rm9200, and we're maintaining quite a set of diffs from stock FreeBSD. Some are bug fixes, some are enhancements such as allowing the master clock frequency to be changed during kernel init (instead of in the bootloader) and a hints-based system that allows the atmelarm bus to become aware of new child devices that aren't in the stock code and manage their resources. It sure would be nice if some of those diffs could get rolled back in; it would certainly make it easier for me to integrate things like Marius' style cleanups back into our repo. Anyway, if ongoing changes are going to be happening to the at91 code, I'm certainly interested in helping however I can. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 14 17:35:40 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A301106566C; Sat, 14 Apr 2012 17:35:40 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 116B28FC0A; Sat, 14 Apr 2012 17:35:38 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA01605; Sat, 14 Apr 2012 20:35:37 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SJ6sr-0008br-8i; Sat, 14 Apr 2012 20:35:37 +0300 Message-ID: <4F89B567.6090008@FreeBSD.org> Date: Sat, 14 Apr 2012 20:35:35 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120317 Thunderbird/10.0.3 MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org, freebsd-fs@FreeBSD.org References: <4F8999D2.1080902@FreeBSD.org> In-Reply-To: <4F8999D2.1080902@FreeBSD.org> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit Cc: Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 17:35:40 -0000 on 14/04/2012 18:37 Andriy Gapon said the following: > > I would like to ask for a review and/or testing of the following three patches: > http://people.freebsd.org/~avg/zfsboot.patches.diff > > These patches add support for booting from an arbitrary filesystem of any > detected ZFS pool. A filesystem could be selected in zfsboot and thus will > affectfrom where zfsloader would be loaded. zfsboot passes information about > the boot pool and filesystem to zfsloader, which uses those for loaddev and > default value of currdev. A different pool+filesystem could be selected in > zfsloader for booting kernel. Also if vfs.root.mountfrom is not explicitly set > and is not derived from fstab, then it gets set to the selected boot filesystem. A note for prospective testers: the patched loader expect to be started by the patched zfs boot as it passes an additional parameter for a filesystem guid. I should probably add some way to distinguish between the older and newer zfs boot blocks. Maybe an extra bit in bootflags? What do you think? > This should could be used as a foundation for the support of Solaris-like boot > environment selection. I believe that other people have already developed > scripts utilizing ZFS capabilities to provide other aspects of management of > boot environments. > > I am particularly interested in reviews of my attempt to make ZFS boot support > arch-independent. The arches, of course, would have to add some code to make > use of that support. Currently I only enabled it for x86. > > Thank you very much! -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 14 17:50:37 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 409DF106566B; Sat, 14 Apr 2012 17:50:37 +0000 (UTC) (envelope-from adutkowski@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9F5338FC15; Sat, 14 Apr 2012 17:50:36 +0000 (UTC) Received: by eaaf13 with SMTP id f13so1088434eaa.13 for ; Sat, 14 Apr 2012 10:50:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=7VMc9kHBNvrJ66gLzAjW9+1/xF/73D2em/fNcsrqYIY=; b=0OpTQUA49CenPQ0oKY15BEKowzhqVmnmEHHT5HIu4I/jx3ZPg2tpe/L1IyKGsECB30 LggGpOHwrYkJb9g8OatOebuZLz0JgelDPJvUC+KCvviqR6SUBYCS7j5vPU0dXN4qSiAb Ox7mQdstjPgvoTJihY84gQp1re5PTsN5OXe7E49QxtlDsCxeqvtaWLcD4hjWFNX00xpY uG5imTHc2IIIGOMTH39TYV28O3Xr7CRX3aCu5DL/9007U3ojlJsd+Nmh4xy5nPl0I179 7e1RIiWlBNfDvgz3ed1r55bKTmy16rZFI054xNFXnt/6t/dPHeIpdxyHNbzp4fHajbba WOjg== MIME-Version: 1.0 Received: by 10.14.183.194 with SMTP id q42mr789434eem.130.1334425835727; Sat, 14 Apr 2012 10:50:35 -0700 (PDT) Received: by 10.213.16.133 with HTTP; Sat, 14 Apr 2012 10:50:35 -0700 (PDT) In-Reply-To: <1334419376.1082.162.camel@revolution.hippie.lan> References: <1334419376.1082.162.camel@revolution.hippie.lan> Date: Sat, 14 Apr 2012 19:50:35 +0200 Message-ID: From: Aleksander Dutkowski To: Ian Lepore , freebsd-arm@freebsd.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: [GSoC] [ARM] arm cleanup - my own proposal X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 17:50:37 -0000 hi Ian! I sent a proposal of porting FBSD for some board. Whether I will be accepted or not, I will contribute to at91 as I have my at91 board. I will send you an email, or you can tell me your irc contact on freenode or efnet, and I will send you my patches for testing :) regards, Aleksander aleek@freenode, aleek@efnet On Sat, Apr 14, 2012 at 6:02 PM, Ian Lepore wrote: > On Sun, 2012-04-01 at 20:19 +0200, Aleksander Dutkowski wrote: >> hello! >> >> after few weeks searching for interesting idea for me, I've decided to >> propose my own one. It is already mentioned on IdeasPage: >> - ARM cleanup >> >> Why I have chosen this one? I am very interested in embedded world. >> Now I am working on porting FBSD to at91sam9g45 - I will be much more >> motivated working on arm fbsd project than any other. >> >> Why should you let me do that project? While working on freebsd/arm >> I've noticed places that could be optimized, or separated, i.e. >> at91_samsize() should be declared for each board separately - now, >> this function has if-else and checks, which board is he running on. >> >> I would like to identify and fix that bugs, so the code will be more >> efficient and clear. Moreover, I think there should be a >> tutorial/framework for adding new boards or SoCs, so I will be >> simplier. I am currently reading the code in sys/arm/at91 and >> searching for improvements but I will be very pleased, if you send me >> your insights. >> >> The first question is - should I cleanup only at91 branch or more? I >> am quite familiar with at91 right now. >> The second - how to test the code? Some of boards could be tested in >> qemu, I could buy board with at91rm9200 for example, if I'm in. But >> maybe I will find here people with their own boards, they could help >> me testing? I havs sbc6045 board with at91sam9g45 SoC but it hasn't >> fbsd support yet (I'm working on it now :) ) >> >> I also thought about reducing kernel size for embedded, if arm cleanup >> won't fit. >> >> > > I'm curious whether you ever got a reply to this privately, since > nothing appeared on the list? =A0I meant to reply and offer to do testing > of at91 changes on rm9200 hardware, but I was on vacation when you > posted originally, and I forgot to reply until just now. > > It's been my growing impression for about a year that the arm support in > FreeBSD has atrophied to the point where it can barely be said that it's > supported at all. =A0Now I see this morning that marius@ has committed a > set of style cleanups to the at91 code (r234281), so maybe it's not > quite as dead as I feared. > > At Symmetricom we build a variety of products based on the rm9200, and > we're maintaining quite a set of diffs from stock FreeBSD. =A0Some are bu= g > fixes, some are enhancements such as allowing the master clock frequency > to be changed during kernel init (instead of in the bootloader) and a > hints-based system that allows the atmelarm bus to become aware of new > child devices that aren't in the stock code and manage their resources. > It sure would be nice if some of those diffs could get rolled back in; > it would certainly make it easier for me to integrate things like > Marius' style cleanups back into our repo. > > Anyway, if ongoing changes are going to be happening to the at91 code, > I'm certainly interested in helping however I can. > > -- Ian > > From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 14 18:37:47 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F124E106564A; Sat, 14 Apr 2012 18:37:47 +0000 (UTC) (envelope-from dmarion.freebsd@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 503718FC08; Sat, 14 Apr 2012 18:37:47 +0000 (UTC) Received: by wgbds12 with SMTP id ds12so3971231wgb.31 for ; Sat, 14 Apr 2012 11:37:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=9jHddATNoxrSlsRcdHFncUznoCYoCzsiHbslU/7QZ5U=; b=ed3au9/CuO3LB9RDaPkq1DYqQ0XuGjAcSWmz60edaK0AIVe33j/HFT8W9WkvFPsN1J Y18F0SInYK0EG0LJvAMDL9V0mS9QACCdA/eo/Y/yX33yEnzIUoAmVeSQ8pbcQNTJ7MIJ yR9YWqA3XNK/sHOLUgEQF2/Uxi6Ik5Ap/xFF3eUR3I70lb7TU51bbJ/66AqOjIQgjY25 OLNERNcOCg7tcKkhWTlf7v35G8eXI+cMCw1uHKL0fvwOlQN3J47L8oYnqcXx1WnZ1SwR lZubPPBDVHm4d5hnQ1qJi1OeyN2RhotTlZjV5qClB3T2Hsk3Xg83enNjqS9BDw63VafS h53Q== Received: by 10.180.103.35 with SMTP id ft3mr5772637wib.0.1334428666243; Sat, 14 Apr 2012 11:37:46 -0700 (PDT) Received: from damarion-mac.home (cpe-109-60-76-207.zg3.cable.xnet.hr. [109.60.76.207]) by mx.google.com with ESMTPS id h8sm10236360wix.4.2012.04.14.11.37.44 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 14 Apr 2012 11:37:45 -0700 (PDT) Sender: Damjan Marion Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Damjan Marion In-Reply-To: <1334419376.1082.162.camel@revolution.hippie.lan> Date: Sat, 14 Apr 2012 20:37:41 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <1334419376.1082.162.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1257) Cc: freebsd-hackers@freebsd.org, freebsd-arm@freebsd.org, Aleksander Dutkowski Subject: Re: [GSoC] [ARM] arm cleanup - my own proposal X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 18:37:48 -0000 On Apr 14, 2012, at 6:02 PM, Ian Lepore wrote: > It's been my growing impression for about a year that the arm support in > FreeBSD has atrophied to the point where it can barely be said that it's > supported at all. Now I see this morning that marius@ has committed a > set of style cleanups to the at91 code (r234281), so maybe it's not > quite as dead as I feared. Hi Ian, Are you aware of projects/armv6[1] in svn? Due to big changes in architecture introduced with ARMv6 we have separate tree where all ongoing development is happening. Hopefully we will be able to merge back changes to HEAD soon. We have (partially) working support for recent Marvel SoC and some TI boards (PandaBoard/OMAP4, Beaglebone/AM335x). There is also OMAP3 code waiting to be integrated. Also Andrew is working on moving to ARM EABI[2] which will allow us to use llvm/clang and all new ARM goodies which are not supported in our aged gcc. Any help is welcome... Damjan [1] http://svnweb.freebsd.org/base/projects/armv6/ [2] http://svnweb.freebsd.org/base/projects/arm_eabi From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 14 21:29:40 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB019106566B for ; Sat, 14 Apr 2012 21:29:40 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5C2438FC0A for ; Sat, 14 Apr 2012 21:29:40 +0000 (UTC) Received: by lagv3 with SMTP id v3so4038197lag.13 for ; Sat, 14 Apr 2012 14:29:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=9r+G8va3B9aT9oyLiT/4gx9ASJ6EyceKA0ML2a8WIL8=; b=Eo7ZX+kL6IQegWPUR802scicZ4uGCIxEs+CNnwjNj1oXo3Bk+2asLeMR2ayYnC3yOl Xjy355rV9mlhXVQv4L/y1ino1c6ltvMoe7buaMJxujsdaPmmLMGqWHzFSoJgru/aRqBy WA18eU9FQ3PJ1y9NqPgMgPB0eWaB5HDmpet8DWTYFdVX7bQNGZPKn3u/XeMSfavYI+rr 0HAmYaZOpByiKE8qDhywSrCHlw3X/dHEBXo4a6nSPje5PcvHVvRD1NSSPvXW6pc77cYB a8NdigxY4Qx7jkXvc+Q8WriFmRJM+92odvZ6POc/4qDKr7ARLV4w+58qODqfZgsJRiWo p8Hg== MIME-Version: 1.0 Received: by 10.112.37.132 with SMTP id y4mr2879786lbj.8.1334438973005; Sat, 14 Apr 2012 14:29:33 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.93.138 with HTTP; Sat, 14 Apr 2012 14:29:32 -0700 (PDT) In-Reply-To: <1334333913.65753.YahooMailNeo@web193204.mail.sg3.yahoo.com> References: <1334333913.65753.YahooMailNeo@web193204.mail.sg3.yahoo.com> Date: Sat, 14 Apr 2012 22:29:32 +0100 X-Google-Sender-Auth: M2vlHzCFKWnSWYAcYCuBmbSzRbM Message-ID: From: Attilio Rao To: Mahesh Babu Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" Subject: Re: Regarding core disable in FreeBSD 9 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 21:29:40 -0000 Il 13 aprile 2012 17:18, Mahesh Babu ha scritto: > How to disable a particular core in FreeBSD 9? > How to enable it again? You can disable specific core at boot time by using the tunable: hint.lapic.X.disabled=1 where X is the APIC ID of the CPU you want to turn off. Attilio -- Peace can only be achieved by understanding - A. Einstein