On Wed, Feb 01, 2012 at 01:05:41AM +0100, Mateusz Guzik wrote:
> Hello,
>
> one pr ( http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/156423 )
> contains request to add kqueue support to /dev/klog.
>
> Assuming that this is a desirable feature, how about this patch (based
> on audit pipe's code):
On Sat, Feb 11, 2012 at 04:21:25PM +0200, Alexander Motin wrote:
> At this moment I am using different penalty coefficients for SMT and
> shared caches (for unrelated processes sharing is is not good). No
> problem to add more types there. Separate flag for shared FPU could be
> used to have dif
On Mon, Mar 12, 2012 at 04:00:58PM +0100, Svatopluk Kraus wrote:
> Hi,
>
>I have solved a following problem. If a big file (according to
> 'hidirtybuffers') is being written, the write speed is very poor.
>
>It's observed on system with elan 486 and 32MB RAM (i.e., low speed
> CPU and not
On Tue, Mar 13, 2012 at 01:54:38PM +0100, Svatopluk Kraus wrote:
> On Mon, Mar 12, 2012 at 7:19 PM, Konstantin Belousov
> wrote:
> > On Mon, Mar 12, 2012 at 04:00:58PM +0100, Svatopluk Kraus wrote:
> >> Hi,
> >>
> >> I have solved a followi
On Sat, Mar 17, 2012 at 08:51:25PM +, Robert N. M. Watson wrote:
>
> On 17 Mar 2012, at 19:30, Mikolaj Golub wrote:
>
> > Currently we can check and change binary osreldate of another process via
> > procfs(5).
> >
> > Kostik suggested to add a new sysctl for the same purpose and also extend
On Sat, Mar 17, 2012 at 11:07:24PM +0200, Mikolaj Golub wrote:
>
> On Sat, 17 Mar 2012 16:37:02 -0400 Jason Hellenthal wrote:
>
> JH> Would this be a planned MFC to stable/N as well specifcially 8 ?
>
> I plan to MFC to stable/9 if there is no objections.
I do not see why the merge to stable/8
On Thu, Mar 15, 2012 at 08:00:41PM +0100, Svatopluk Kraus wrote:
> 2012/3/15 Konstantin Belousov :
> > On Tue, Mar 13, 2012 at 01:54:38PM +0100, Svatopluk Kraus wrote:
> >> On Mon, Mar 12, 2012 at 7:19 PM, Konstantin Belousov
> >> wrote:
> >> > On Mon, Mar
On Wed, Mar 21, 2012 at 04:35:13PM -0700, Sushanth Rai wrote:
> Sometimes I have trouble capturing the "correct" state of a
> multithreaded process using gcore. That is, it looks like target
> process might have done some work since the time command was issued
> and the core file was generated.
>
>
On Fri, Mar 23, 2012 at 12:35:17AM -0700, Sushanth Rai wrote:
> What I mean by inconsistent is that, a process with lots of threads
> takes a while before all threads are suspended. When I look at the
> resulting core file, the state of some of the shared data is not
> exactly what I was expecting
On Sat, Mar 24, 2012 at 12:52:29AM -0700, Sushanth Rai wrote:
>
>
> --- On Fri, 3/23/12, Konstantin Belousov wrote:
>
>
> Can we
> > > safely remove them out of the runq ?
> > No, since thread on runq shall be considered the same as the
> > thread
>
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 w
On Wed, Apr 04, 2012 at 06:54:06PM -0700, Sushanth Rai wrote:
> I have a multithreaded user space program that basically runs at realtime
> priority. Synchronization between threads are done using spinlock. When
> running this program on a SMP system under heavy memory pressure I see that
> thre
On Thu, Apr 05, 2012 at 10:54:31AM -0500, 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,
&
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
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 wro
On Thu, Apr 05, 2012 at 01:25:49PM -0500, Alan Cox wrote:
> On 04/05/2012 12:31, Konstantin Belousov wrote:
> >On Thu, Apr 05, 2012 at 10:54:31AM -0500, Alan Cox wrote:
> >>On 04/04/2012 02:17, Konstantin Belousov wrote:
> >>>On Tue, Apr 03, 2012 at 11:02:53PM +0400
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:
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,
On Mon, Apr 09, 2012 at 07:37:11PM -0700, Sushanth Rai wrote:
> 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() i
On Tue, Apr 10, 2012 at 06:33:44PM -0700, Sushanth Rai wrote:
>
> > > 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);
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 standa
On Thu, Apr 12, 2012 at 08:10:26PM -0700, Sushanth Rai wrote:
> >
> > 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 alloc
9fe000 1 0 0xff002dd7fd80 rw- 1 0 0x3100 NCOW NNC
> not-wired default -
> 0x7fbdf000 0x7fbff000 1 0 0xff002dbe9438 rw- 1 0 0x3100 NCOW NNC
> not-wired default -
> 0x7fbff000 0x7fc0 0 0 0 --- 0 0 0x0 NCOW NNC not-wired none -
> 0x7ffe0000 0x8000
On Sun, Apr 15, 2012 at 01:54:42AM -0700, Yuri wrote:
> On 04/05/2012 07:06, John Baldwin wrote:
> >In this case we probably should become the upstream maintainer. My patch
> >actually bumps the version to 1.3 as it is sort of intended to do that.
>
> bsd-pstack on SourceForge is dead. Sole proje
On Mon, Apr 16, 2012 at 03:08:25PM -0400, Ewart Tempest wrote:
> In FreeBSD 6.*, we have been seeing crashes in pmap_remove_pages() that only
> seem to occur in scaling scenarios:
>
> 2564#ifdef PMAP_REMOVE_PAGES_CURPROC_ONLY
> 2565pte = vtopte(pv->pv_va);
> 2566#else
On Wed, Apr 18, 2012 at 01:36:26PM +0300, Andriy Gapon wrote:
>
> I just would like to share something that I stumbled upon.
> Maybe this is something well known, then forgive me for the noise.
>
> When ld combines multiple object files it overrides weak symbol definitions
> with
> a strong defi
On Wed, Apr 18, 2012 at 04:37:45PM -0700, Sushanth Rai wrote:
> Wiring entire address space seems to have interesting side effect. The
> libc memory allocator calls madvise() to free the dirty unused pages,
> which does nothing when the pages are wired. The allocator unmaps only
> when entire chunk
On Sun, May 27, 2012 at 05:33:30PM -0600, Jamie Gritton wrote:
> On 05/25/12 10:48, Sean Bruno wrote:
> >I've been toying with the idea of letting jails renice processes ... how
> >dangerous and/or stupid is this idea?
> >
> > //depot/yahoo/ybsd_9/src/sys/kern/kern_jail.c#5 -
> >/home/seanbru/y
On Sat, Jun 02, 2012 at 11:34:21PM +, Benjamin Kaduk wrote:
> Hi all,
>
> My colleague recently pointed out to me that I was calling vgone() when I
> probably wanted to be using cache_purge() (as is done for implementations
> of this OS-specific function in other BSDs [1]).
>
> This caused
On Thu, Jun 07, 2012 at 10:45:26AM +0300, Andriy Gapon wrote:
>
> It's long been a wish of mine to have an ability to decide at boot time that a
> system should boot in "console-only" mode. That is, that no graphics/X
> applications like e.g. xdm/kdm/gdm are automatically started even when they
On Sat, Jun 09, 2012 at 10:31:17AM +0300, Mikolaj Golub wrote:
>
> On Fri, 1 Jun 2012 14:54:48 +0200 Ivan Voras wrote:
>
> IV> On 1 June 2012 14:35, Wojciech Puchar
> wrote:
> >>> http://people.freebsd.org/~ivoras/stuff/spsurvey.py
>
> ...
>
> IV> If anyone posts more data, I'll analyse i
On Sat, Jun 09, 2012 at 12:03:43PM +0300, Mikolaj Golub wrote:
>
> On Sat, 9 Jun 2012 11:38:22 +0300 Konstantin Belousov wrote:
>
> KB> On Sat, Jun 09, 2012 at 10:31:17AM +0300, Mikolaj Golub wrote:
> >>
> >> On Fri, 1 Jun 2012 14:54:48 +0200 Ivan Voras w
On Sat, Jun 09, 2012 at 12:46:53PM +0300, Mikolaj Golub wrote:
>
> On Sat, 9 Jun 2012 12:07:40 +0300 Konstantin Belousov wrote:
>
> KB> Well, if I see a report informing me that some 2M region contains 512
> super
> KB> pages, how should I interpret it ? For me,
On Sat, Jun 09, 2012 at 10:27:03AM -0600, Ian Lepore wrote:
> On Sat, 2012-06-09 at 09:21 +0200, Wojciech Puchar wrote:
> > top reports wired memory 128MB
> >
> >
> > WHERE it is used? below results of vmstat -m and vmstat -z
> > values does not sum up even to half of it
> > FreeBSD 9 - few days
On Tue, Jun 12, 2012 at 08:51:34AM -0600, Ian Lepore wrote:
> On Sat, 2012-06-09 at 22:45 +0200, Wojciech Puchar wrote:
> > >
> > > First, all memory allocated by UMA and consequently malloc(9) is
> > > wired. In other words, almost all memory used by kernel is accounted
> > > as wired.
> > >
> > y
On Wed, Jun 13, 2012 at 07:14:09AM -0600, Ian Lepore wrote:
> On Tue, 2012-06-12 at 23:45 +0300, Konstantin Belousov wrote:
> > On Tue, Jun 12, 2012 at 08:51:34AM -0600, Ian Lepore wrote:
> > > On Sat, 2012-06-09 at 22:45 +0200, Wojciech Puchar wrote:
> > > >
use rtld always holds bind_lock exclusively while loading
an object. There is no need to copy the first page after it is mapped.
commit 0f6f8629af1345acded7c0c685d3ff7b4d9180d6
Author: Konstantin Belousov
Date: Wed Jun 13 22:04:18 2012 +0300
Eliminate the static buffer used to read the fi
On Wed, Jun 13, 2012 at 03:17:56PM -0500, Alan Cox wrote:
> On Wed, Jun 13, 2012 at 2:12 PM, Konstantin Belousov
> wrote:
>
> > On Wed, Jun 13, 2012 at 07:14:09AM -0600, Ian Lepore wrote:
> > > http://lists.freebsd.org/pipermail/freebsd-arm/2012-January/003288.html
> &
On Thu, Jun 14, 2012 at 08:20:02AM -0400, John Baldwin wrote:
> On Thursday, June 14, 2012 12:30:19 am Adrian Chadd wrote:
> > On 13 June 2012 21:26, Mark Linimon wrote:
> > > On Wed, Jun 13, 2012 at 08:50:24AM -0700, Garrett Cooper wrote:
> > >> The only way that this would really work is if ther
On Sat, Jun 23, 2012 at 02:17:53PM +0800, David Xu wrote:
> On 2012/06/21 20:11, John Baldwin wrote:
> >On Monday, June 18, 2012 2:56:30 pm Daniil Cherednik wrote:
> >>Hi!
> >>
> >>I am trying to continue the work started by DavidXu on implemention of
> >>fast
> >>syscalls via sysenter/sysexit.
>
On Tue, Jul 10, 2012 at 03:16:45PM +0300, Volodymyr Kostyrko wrote:
> Hi all.
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/149857
>
> This PR is rather old. I just had submitted new test case, now in plain c.
>
> It doesn't work exactly like python version, but the result is the same:
>
On Tue, Jul 10, 2012 at 05:19:05PM +0300, Volodymyr Kostyrko wrote:
> Konstantin Belousov wrote:
> >>This PR is rather old. I just had submitted new test case, now in plain c.
> >>
> >>It doesn't work exactly like python version, but the result is the same:
>
On Tue, Jul 10, 2012 at 06:02:50PM +0300, Volodymyr Kostyrko wrote:
> Konstantin Belousov wrote:
> >>So you mean this is just my false assumption that EOF _should_ occur on
> >>stdin? And it actually occurs only if source is a process which can send
> >>EOF?
>
On Thu, Jul 12, 2012 at 04:41:58PM -0600, Ian Lepore wrote:
> On Tue, 2012-06-19 at 06:47 +0200, Wojciech Puchar wrote:
> > that is what i need.
> >
> > but still need some explanation after using it and reading manual
> >
> > say:
> >PID STARTEND PRT RES PRES RE
On Sun, Jul 15, 2012 at 07:32:35PM +0200, Dimitry Andric wrote:
> On 2012-07-15 15:39, Jakub Lach wrote:
> > While this is old "bug" upstream:
> >
> > http://llvm.org/bugs/show_bug.cgi?id=8611
> >
> > http://llvm.org/bugs/show_bug.cgi?id=8630
> >
> > Here,
> >
> > (FreeBSD clang version 3.1 (b
On Mon, Jul 23, 2012 at 02:54:30AM -0400, Richard Yao wrote:
> What is the default kernel thread stack size on FreeBSD? I am
> particularly interested in knowing about i386 and amd64, but knowing
> this for other architectures (such as MIPS) would also be useful.
>
Look for the KSTACK_PAGES symbo
On Mon, Jul 30, 2012 at 12:24:08PM +0200, Jilles Tjoelker wrote:
> People sometimes use system() from large address spaces where it would
> improve performance greatly to use vfork() instead of fork().
>
> A simple approach is to change fork() to vfork(), although I have not
> tried this. It seems
On Thu, Aug 02, 2012 at 05:50:25PM +0400, Andrey Zonov wrote:
> Hi,
>
> It would be useful to have system wide major and minor page faults
> counters. Attached patch makes this possible.
>
> Are there any objections to have it?
I thought that struct vmmeter was engraved into our ABI much deeper
On Sun, Aug 05, 2012 at 11:54:32PM +0200, Jilles Tjoelker wrote:
> On Mon, Jul 30, 2012 at 01:53:03PM +0300, Konstantin Belousov wrote:
> > On Mon, Jul 30, 2012 at 12:24:08PM +0200, Jilles Tjoelker wrote:
> > > People sometimes use system() from large address spaces where it w
On Thu, Aug 09, 2012 at 12:56:49PM +0200, Jilles Tjoelker wrote:
> On Mon, Aug 06, 2012 at 11:25:35AM +0300, Konstantin Belousov wrote:
> > No, other running threads in parent affect vforked child till exec or exit.
> > In fact, I would classify this as bug, but not a serious one.
On Thu, Aug 09, 2012 at 02:08:50PM +0300, Konstantin Belousov wrote:
> Third alternative, which seems to be even better, is to restore
> single-threading of the parent for vfork().
I mean this patch.
diff --git a/sys/kern/kern_fork.c b/sys/kern/kern_fork.c
index 6cb95cd..e59ee21 100644
On Fri, Aug 10, 2012 at 12:06:46PM -0400, Dan Plassche wrote:
> Hello,
>
> I'm successfully running FreeBSD 1.1.5.1 binaries from a
> directory on an 8.2 system. The goal is to ultimately setup a
> chroot build environment targeting 1.x for an old 386. However,
> whenever I chroot to the /freebs
Why did you stripped the public list from the Cc: ?
On Fri, Aug 10, 2012 at 05:05:09PM -0400, Dan Plassche wrote:
> On Fri, Aug 10, 2012 at 1:07 PM, Konstantin Belousov
> wrote:
>
> > Try to ktrace the binaries to see what is going on. I suspect that
> > sources for 1.1.5 a
On Sun, Aug 12, 2012 at 08:11:29AM +0800, David Xu wrote:
> On 2012/08/10 18:13, Konstantin Belousov wrote:
> >On Thu, Aug 09, 2012 at 02:08:50PM +0300, Konstantin Belousov wrote:
> >>Third alternative, which seems to be even better, is to restore
> >>single-thread
On Tue, Aug 14, 2012 at 12:42:15PM +0800, David Xu wrote:
> I simply duplicated idea from OpenSolaris, here is my patch
> which has similar feature as your patch, and it also tries to
> prevent vforked child from corrupting parent's data:
> http://people.freebsd.org/~davidxu/patch/libthr-vfork.diff
On Tue, Aug 14, 2012 at 05:16:56PM +0800, David Xu wrote:
> On 2012/08/14 16:18, Konstantin Belousov wrote:
> >On Tue, Aug 14, 2012 at 12:42:15PM +0800, David Xu wrote:
> >>I simply duplicated idea from OpenSolaris, here is my patch
> >>which has similar feature as your
On Mon, Aug 13, 2012 at 06:28:46PM -0700, Julian Elischer wrote:
> On 8/13/12 3:33 PM, Dan Plassche wrote:
> >Konstantin,
> >
> >My apologies for any confusion. Your patch solved the problem on
> >8.2. Static and dynamic a.out binaries from 1.1.5.1 are working
> >normally in a chroot environment
On Wed, Aug 15, 2012 at 03:55:37AM -0700, Julian Elischer wrote:
> On 8/15/12 3:29 AM, Julian Elischer wrote:
> >On 8/14/12 6:07 AM, Konstantin Belousov wrote:
> >>On Mon, Aug 13, 2012 at 06:28:46PM -0700, Julian Elischer wrote:
> >>>On 8/13/12 3:33 PM, Dan Pl
On Tue, Aug 14, 2012 at 11:15:06PM +0800, David Xu wrote:
> You are requiring the thread library to implement such a mutex
> and other locks, that after vfork(), the mutex and other lock types must
> still work across processes, the PTHREAD_PROCESS_PRIVATE type of
> mutex and other locks now need t
On Wed, Aug 15, 2012 at 07:40:04AM +0800, David Xu wrote:
> On 2012/08/15 05:09, Jilles Tjoelker wrote:
> >On Tue, Aug 14, 2012 at 11:15:06PM +0800, David Xu wrote:
> >>But in real word, pthread atfork handlers are not async-signal safe,
> >>they mostly do mutex locking and unlocking to keep consis
On Thu, Aug 16, 2012 at 08:23:39AM +0800, David Xu wrote:
> On 2012/08/16 01:49, Konstantin Belousov wrote:
> >On Wed, Aug 15, 2012 at 07:40:04AM +0800, David Xu wrote:
> >>On 2012/08/15 05:09, Jilles Tjoelker wrote:
> >>>On Tue, Aug 14, 2012 at 11:15:06PM +0800, Dav
On Wed, Aug 15, 2012 at 05:32:03PM -0400, Dan Plassche wrote:
> On Mon, Aug 13, 2012 at 9:28 PM, Julian Elischer
> wrote:
>
> > you will also have to change PID_MAX (spelling?) to be 6
> > I have considered making this a tunable..
> > If you don't then the shell in the 1.1.5.1 environment wil
On Fri, Aug 17, 2012 at 12:39:33AM +0200, Jilles Tjoelker wrote:
> On Thu, Aug 16, 2012 at 02:44:26PM +0300, Konstantin Belousov wrote:
> > My point is that the fact that fork() is called from dynamic context
> > that was identified as the signal handler does not mean anything.
&g
On Fri, Aug 17, 2012 at 06:08:47PM +0200, Jilles Tjoelker wrote:
> On Fri, Aug 17, 2012 at 03:43:12PM +0300, Konstantin Belousov wrote:
> > On Fri, Aug 17, 2012 at 12:39:33AM +0200, Jilles Tjoelker wrote:
> > > On Thu, Aug 16, 2012 at 02:44:26PM +0300, Konstantin Belousov
On Mon, Aug 20, 2012 at 08:32:41PM -0600, Dan McGregor wrote:
> Hi.
>
> I've been working on porting compiler-rt/clang's support for address
> sanitization (asan) to FreeBSD. So far I have it building and it
> appears to work properly, however the build system expects to be able
> to build 32 bit
On Wed, Aug 22, 2012 at 10:09:27PM +0200, Tijl Coosemans wrote:
> On 21-08-2012 17:04, Dan McGregor wrote:
> > My solution is certainly fairly hacky, I just took inspiration from
> > NetBSD. I wanted to see if it could be done. While I was there I did
> > identify several files that should be com
On Fri, Aug 24, 2012 at 09:17:22AM -0600, John Hein wrote:
>
> head sl.cc pe.c
> ==> sl.cc <==
> #include
> #include
> class C
> {
> public:
> C(){
> printf("C\n");
> unsetenv("XXX");
> }
> };
> static C c;
>
> ==> pe.c <==
> #include
> #include
> int
> main()
> {
> char *p=getenv("XX
On Sat, Aug 25, 2012 at 12:16:55AM +0200, Jilles Tjoelker wrote:
> For some reason, libc exports the symbol .cerror (HIDENAME(cerror)),
> albeit in the FBSDprivate_1.0 version. It looks like there is no reason
> for this since it is not used from other libraries. Given that it cannot
> be accessed
On Wed, Aug 29, 2012 at 09:09:17AM -0700, Patrick Mahan wrote:
> All,
>
> I'm trying to determine if this is a bug or for real. We have a customer
> that pointed his
> NMS at our appliance (running FBSD 9.0). These are 64-bit intel platforms (8
> core Xeons)
> with 8 Gbytes of RAM and a 16 Gby
On Sat, Sep 01, 2012 at 12:48:50AM +0200, Jilles Tjoelker wrote:
> On Tue, Aug 28, 2012 at 02:03:22PM +0300, Konstantin Belousov wrote:
> > On Sat, Aug 25, 2012 at 12:16:55AM +0200, Jilles Tjoelker wrote:
> > > Not exporting .cerror causes it to be jumped to directly instead of
On Mon, Sep 03, 2012 at 09:46:17PM -0400, Sam Varshavchik wrote:
> Am I the only one who's seeing this weirdness with procfs on
> 9.0-RELEASE-p3. Unless I'm overlooking something stupid, a process that
> rmdir(2)s a subdirectory of its current directory ends up with a broken
> /proc/curproc/f
On Tue, Sep 04, 2012 at 11:50:35PM +0200, Dimitry Andric wrote:
> On 2012-09-04 17:53, Eitan Adler wrote:
> >On 4 September 2012 05:26, Jake Smith wrote:
> ...
> >>It got me thinking, is there any reason why it would be a bad idea to
> >>build
> >>all my ports with debug symbols from now on?
> >
On Fri, Sep 07, 2012 at 10:33:52AM -0400, John Baldwin wrote:
> On Tuesday, September 04, 2012 7:46:23 pm Sam Varshavchik wrote:
> > Is the dev+ino of what was exec()ed known, for another process? I might be
> > able to get the client voluntarily submit its argv[0], then independently
> > have
On Fri, Sep 07, 2012 at 12:23:54PM -0400, John Baldwin wrote:
> On Friday, September 07, 2012 11:59:36 am Konstantin Belousov wrote:
> > On Fri, Sep 07, 2012 at 10:33:52AM -0400, John Baldwin wrote:
> > > On Tuesday, September 04, 2012 7:46:23 pm Sam Varshavchik wrote:
> &g
On Tue, Sep 18, 2012 at 05:46:23PM +0200, Dag-Erling Sm??rgrav wrote:
> The patch below my signature improves the legibility of fdgrowtable(),
> and adds comments explaining the hairier bits. The only functional
> change is that the code no longer overwrites the old fileflags array
> when the old
On Wed, Sep 19, 2012 at 02:58:02PM +0200, Dag-Erling Sm??rgrav wrote:
> Konstantin Belousov writes:
> > "Dag-Erling Sm??rgrav" writes:
> > > + otable = fdp->fd_ofiles;
> > > + ofileflags = fdp->fd_ofileflags;
> > These two new calculations cou
On Wed, Sep 19, 2012 at 09:04:30PM +0200, Dag-Erling Sm??rgrav wrote:
> Konstantin Belousov writes:
> > "Dag-Erling Sm??rgrav" writes:
> > > I assume you mean assignments, not calculations. I trust the compiler
> > > to move them to where they are nee
On Wed, Sep 26, 2012 at 11:14:41AM +0300, Andriy Gapon wrote:
>
> Typical x86 MONITOR+MWAIT is like this (taken from Intel manual):
>
> EAX = Logical Address(Trigger)
> ECX = 0 (*Hints *)
> EDX = 0 (* Hints *)
> IF ( !trigger_store_happened) {
> MONITOR EAX, ECX, EDX
> IF ( !trigger_s
On Sun, Oct 07, 2012 at 03:17:30PM +0300, Andriy Gapon wrote:
>
> I noticed that couple of our userland file include machine/cpu.h for no
> apparent
> good reason. It looks like at least amd64 cpu.h has no userland serviceable
> parts inside.
> Maybe its content should be put under _KERNEL ?
>
On Thu, Oct 18, 2012 at 10:08:22AM +1000, Tristan Verniquet wrote:
>
> I want to work with large (1-10G) files in memory but eventually sync
> them back out to disk. The problem is that the sync process appears to
> lock the file in kernel for the duration of the sync, which can run
> into minutes
On Thu, Oct 18, 2012 at 09:39:34AM -0400, John Baldwin wrote:
> On Thursday, October 18, 2012 4:35:37 am Konstantin Belousov wrote:
> > On Thu, Oct 18, 2012 at 10:08:22AM +1000, Tristan Verniquet wrote:
> > >
> > > I want to work with large (1-10G) files in memory but
On Thu, Oct 18, 2012 at 03:43:25PM -0400, John Baldwin wrote:
> On Thursday, October 18, 2012 12:42:18 pm Konstantin Belousov wrote:
> > On Thu, Oct 18, 2012 at 09:39:34AM -0400, John Baldwin wrote:
> > > On Thursday, October 18, 2012 4:35:37 am Konstantin Belousov wrote:
>
On Thu, Oct 25, 2012 at 03:53:53PM -0700, Simon J. Gerraty wrote:
>
> On Thu, 25 Oct 2012 23:01:27 +0100, Chris Rees writes:
> >Is there a Wiki page where the actual benefits of moving to bmake are
> >made clear? This is a major, *major* upheaval, and having two
> >versions of bsd.port.mk for yea
On Fri, Oct 26, 2012 at 11:12:53AM -0700, Simon J. Gerraty wrote:
>
> On Fri, 26 Oct 2012 11:41:46 -0600, Warner Losh writes:
> >It's called a transition period for a reason. The historical use has =
> >permeated itself into many places, not all of which are obvious.
>
> It would seem that leavi
On Tue, Oct 30, 2012 at 10:48:03AM -0700, Alfred Perlstein wrote:
> Some suggestions here, jemalloc, kernel threads are good ones.
>
> Another issue may just be some change for default thread stack size.
> This would explain why the RESIDENT set is the same, but the VIRTUAL grew.
I suggest to ta
On Wed, Oct 31, 2012 at 09:49:21AM +, Karl Pielorz wrote:
>
> --On 30 October 2012 19:51 +0200 Konstantin Belousov
> wrote:
>
> > I suggest to take a look at where the actual memory goes.
> >
> > Start with procstat -v.
>
> Ok, running that for the mil
On Wed, Oct 31, 2012 at 02:44:05PM +, Karl Pielorz wrote:
>
>
> --On 31 October 2012 16:06 +0200 Konstantin Belousov
> wrote:
>
> > Since you neglected to provide the verbatim output of procstat, nothing
> > conclusive can be said. Obviously, you can make an in
On Wed, Oct 31, 2012 at 11:52:06AM -0700, Adrian Chadd wrote:
> On 31 October 2012 11:20, Ian Lepore wrote:
> > I think there are some things we should be investigating about the
> > growth of memory usage. I just noticed this:
> >
> > Freebsd 6.2 on an arm processor:
> >
> > 369 root 1 8 -8
On Sat, Nov 03, 2012 at 01:11:17PM -0500, Alan Cox wrote:
> On Wed, Oct 31, 2012 at 2:06 PM, Konstantin Belousov
> wrote:
>
> > On Wed, Oct 31, 2012 at 11:52:06AM -0700, Adrian Chadd wrote:
> > > On 31 October 2012 11:20, Ian Lepore
> > wrote:
> > > >
On Sat, Nov 03, 2012 at 12:38:39PM -0600, Ian Lepore wrote:
> In an attempt to un-hijack the thread about memory usage increase
> between 6.4 and 9.x, I'm starting a new thread here related to my recent
> discovery that watchdogd uses a lot more memory since it began using
> mlockall(2).
>
> I tri
On Sun, Nov 04, 2012 at 03:37:27PM +0100, Jilles Tjoelker wrote:
> Rtld does not set FD_CLOEXEC on its internal file descriptors;
> therefore, such a file descriptor may be passed to a process created by
> another thread running in parallel to dlopen() or fdlopen().
>
> The race is easy to trigger
On Fri, Nov 09, 2012 at 07:10:04PM +, Sears, Steven wrote:
> I have a memory subsystem design question that I'm hoping someone can answer.
>
> I've been looking at a machine that is completely out of memory, as in
>
> v_free_count = 0,
> v_cache_count = 0,
>
> I wondered how a machine co
On Sun, Nov 11, 2012 at 03:40:24PM -0600, Alan Cox wrote:
> On Sat, Nov 10, 2012 at 7:20 AM, Konstantin Belousov
> wrote:
>
> > On Fri, Nov 09, 2012 at 07:10:04PM +, Sears, Steven wrote:
> > > I have a memory subsystem design question that I'm hoping someone can
On Mon, Nov 12, 2012 at 11:35:42AM -0600, Alan Cox wrote:
> Agreed. Most recently I eliminated several uses from the arm pmap
> implementations. There is, however, one other use:
>
> ofed/include/linux/gfp.h:#defineGFP_ATOMIC (M_NOWAIT |
> M_USE_RESERVE)
Yes, I forgot to mention thi
On Mon, Nov 12, 2012 at 01:28:02PM -0800, Sushanth Rai wrote:
> This patch still doesn't address the issue of M_NOWAIT calls driving
> the memory the all the way down to 2 pages, right ? It would be nice to
> have M_NOWAIT just do non-sleep version of M_WAITOK and M_USE_RESERVE
> flag to dig deep.
On Mon, Nov 12, 2012 at 05:10:01PM -0600, Alan Cox wrote:
> On 11/12/2012 3:48 PM, Konstantin Belousov wrote:
> > On Mon, Nov 12, 2012 at 01:28:02PM -0800, Sushanth Rai wrote:
> >> This patch still doesn't address the issue of M_NOWAIT calls driving
> >> the memory
On Thu, Nov 15, 2012 at 11:32:18AM -0600, Alan Cox wrote:
> On 11/13/2012 05:54, Konstantin Belousov wrote:
> > On Mon, Nov 12, 2012 at 05:10:01PM -0600, Alan Cox wrote:
> >> On 11/12/2012 3:48 PM, Konstantin Belousov wrote:
> >>> On Mon, Nov 12, 2012 at 01:28:
On Sat, Nov 17, 2012 at 11:05:40PM -0800, Perry Hutchison wrote:
> [trimmed some of the lists]
>
> Chris Rees wrote:
> > ... git doesn't work with our workflow.
>
> I'm sure the workflow itself is documented somewhere, but is
> there a good writeup of _how_ git doesn't work with it, e.g. what
>
On Mon, Dec 03, 2012 at 03:11:21PM +, Karl Pielorz wrote:
>
> Hi,
>
> I have two SuperMicro E31220L based systems - both had identical
> /etc/sysctl.conf - I then shifted them from 9.0-R to 9.0-Stable (as of
> 2012/12/03).
>
> Now I've noticed of them complains at boot time that a bunch of
On Tue, Dec 04, 2012 at 03:28:37PM -0500, Rick Macklem wrote:
> Hi,
>
> For my NFSv4.1 client work, I've taken a few definitions out of a
> kernel rpc .c file and put them in a .h file so that they can
> be included in other sys/rpc .c files.
>
> I've currently named the file _krpc.h. I thought I
1 - 100 of 190 matches
Mail list logo
