ths_. I
> don't see how oprofile can do that as it tracks instruction pointers only.
>
> Pekka
You could try passing the --callgraph option to opcontrol.
--
Nicholas Miell <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscr
>
C++ name mangling would be extremely useful here.
Actually, why isn't the DWARF information for the functions sufficient?
--
Nicholas Miell <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [E
y);
t->fn2(x, y);
}
generate instruction-for-instruction identical code.
--
Nicholas Miell <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
rent PID namespaces on the
same machine via a shared file mapping is logically equivalent to
accessing the same robust futex from different machines via a shared
filesystem and there's no reason to expect either operation to work
correctly.
--
Nicholas Miell <[EMAIL PROTECTED]>
-
To u
On Wed, 2007-10-10 at 12:14 +0200, Ingo Molnar wrote:
> * Nicholas Miell <[EMAIL PROTECTED]> wrote:
>
> > Does CFS still generate the following sysbench graphs with 2.6.23, or
> > did that get fixed?
> >
> > http://people.freebsd.org/~kris/scaling/linux-pgsq
th 2.6.23, or
did that get fixed?
http://people.freebsd.org/~kris/scaling/linux-pgsql.png
http://people.freebsd.org/~kris/scaling/linux-mysql.png
(There's also some interesting FreeBSD vs. Linux graphs in
http://people.freebsd.org/~kris/scaling/Scalability%20Update.pdf , but
AFAIK those comparisons
uot; > /sys/bus/pci/drivers/serial/new_id and let
Russell King ([EMAIL PROTECTED]) know if it works (or if it
doesn't, for that matter).
--
Nicholas Miell <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
to
> send to userspace programs. It would also be useful to inform
> userspace programs when we are about to start swapping something
> out, so userspace can discard cached data instead of having to
> wait for disk IO in the future.
>
> A unix signal cannot encapsulate two different
y) called exit.
POSIX says
WIFSIGNALED(stat_val)
Evaluates to a non-zero value if status was returned for a child
process that terminated due to the receipt of a signal that was
not caught (see ).
So there's no dilemma at all and Linux is non-conformant.
y and the resulting
filesystem design it inspired rather than of inotify itself.
Come up with a filesystem where given an inode you can find every
directory that has links to that inode with very little effort, convince
everybody to switch from ext3 to this new filesystem, and then maybe
inotify c
> > I wonder it it also affects the instruction count the inline heuristics
> > use?
>
> AFAIK it counts like one operand.
>
> -Andi
GCC counts newlines and semicolons and uses that number as the likely
instruction count.
See asm_insn_count() in gcc/gcc/final.c
--
Nicholas
t.) It does not take a file descriptor for the file argument.
> > Otherwise we'd also need fopenat/funlinkat, etc. Any reasons?
>
> Ulrich having an odd taste?
Solaris compatibility.
--
Nicholas Miell <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line &quo
s, A and B, are in separate VFS namespaces but have
equivalent security identity according to LSM. Process A reads data from
file F which is not visible in process's B's namespace. You have to
prevent process B from ever getting a page that once contained data from
file F.
3) mlock() i
icholas means... and it may even simplify the code.
>
That is what I was suggesting, but I don't understand the internals of
Linux signal delivery enough to know if it is possible without
unpleasant contortions to make it work.
--
Nicholas Miell <[EMAIL PROTECTED]>
-
To unsubscri
On Fri, 2007-06-22 at 17:12 -0700, Davide Libenzi wrote:
> On Fri, 22 Jun 2007, Nicholas Miell wrote:
>
> > You could just get rid of the process/sighand/whatever reference
> > entirely and just make reads on a signalfd always dequeue signals for
> > the
?
>
> Ah got it, signalfd_detach() in include/linux/signalfd.h from
> exit_signal plus some rcu bits in signalfd lock/unlock.
You could just get rid of the process/sighand/whatever reference
entirely and just make reads on a signalfd always dequeue signals for
the current thread.
You
On Sun, 2007-06-17 at 16:49 -0700, Davide Libenzi wrote:
> On Sun, 17 Jun 2007, Nicholas Miell wrote:
>
> > On Sun, 2007-06-17 at 10:01 -0700, Davide Libenzi wrote:
> > > On Sun, 17 Jun 2007, Nicholas Miell wrote:
> > >
> > > > On Sat, 2007-
On Sun, 2007-06-17 at 10:01 -0700, Davide Libenzi wrote:
> On Sun, 17 Jun 2007, Nicholas Miell wrote:
>
> > On Sat, 2007-06-16 at 20:33 -0700, Linus Torvalds wrote:
> > > In a stunning turn of events, I've actually been able to make another -rc
> > > release
e
> out there!
>
signalfd still has the broken behavior w.r.t. signal delivery to
threads.
Is this going to get fixed before 2.6.22 proper is released, or should
it just be disabled entirely so no userspace apps grow to depend on
current wrong behavior?
--
Nicholas Miell <[EMAIL PROTECTED]&
mprotect and munmap.
I think he's asking for a way to copy an existing mapping, which does
sound genuinely useful. (i.e. mremap(ptr, size, size, MREMAP_COPY), with
no need to mess with files to get multiple mappings of the same region)
--
Nicholas Miell <[EMAIL PROTECTED]>
-
To u
it is blocked in a syscall waiting for signal delivery and the error
is caused by the signal delivery mechanism itself (i.e. a bad pointer
passed to read/select/poll/epoll_wait/etc.) and thus the signal can't be
delivered
--
Nicholas Miell <[EMAIL PROTECTED]>
-
To unsubscribe from
On Tue, 2007-06-05 at 17:37 -0700, Davide Libenzi wrote:
> On Tue, 5 Jun 2007, Nicholas Miell wrote:
>
> > On Tue, 2007-06-05 at 17:11 -0700, Davide Libenzi wrote:
> > > On Tue, 5 Jun 2007, Nicholas Miell wrote:
> > >
> > > > Yes, that's certainly w
On Tue, 2007-06-05 at 17:11 -0700, Davide Libenzi wrote:
> On Tue, 5 Jun 2007, Nicholas Miell wrote:
>
> > Yes, that's certainly wrong, but that's an implementation issue. I was
> > more concerned about the design of the API.
> >
> > Naively, I would expec
On Tue, 2007-06-05 at 17:27 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2007-06-04 at 23:09 -0700, Nicholas Miell wrote:
> > signalfd() doesn't deliver thread-targeted signals to the wrong
> > threads,
> > does it?
> >
> > Hmm.
> >
> > I
fd (regardless of
which thread actually calls read()).
Which is weird, to say the least. Definitely needs to be noted in the
man page, which doesn't seem to exist yet.
Is there a reason why signalfd() doesn't behave like regular signals in
this regard?
--
Nicholas Miell <[EMAIL P
t; #define O_NOATIME0100
> #endif
> +#ifndef O_CLOEXEC
> +#define O_CLOEXEC0200/* set close_on_exec */
> +#endif
> #ifndef O_NDELAY
> #define O_NDELAY O_NONBLOCK
> #endif
O_CLOSEONEXEC, perhaps?
We don't want to create another "cre
- Ted
The AMD64 psABI requires binaries to work with any page size up to 64k.
Whether that's true in practice is another matter entirely, of course.
--
Nicholas Miell <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscri
(sorry for the duplicate Ingo, this time I managed to Repy to All)
On Sat, 2007-03-17 at 08:45 +0100, Ingo Molnar wrote:
> * Nicholas Miell <[EMAIL PROTECTED]> wrote:
>
> > The X people have plans for how to go about fixing this, [...]
>
> then we'll first have w
t to cooperate.
>
The changes will probably be entirely server-side anyway, so stray
ancient libraries won't be a problem.
--
Nicholas Miell <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [E
On Sat, 2007-03-17 at 06:56 +0100, Mike Galbraith wrote:
> On Fri, 2007-03-16 at 21:24 -0700, Nicholas Miell wrote:
>
> > Sorry, I haven't really been following this thread and now I'm confused.
> >
> > You're saying that it's somehow the scheduler&
ibly function.
>
> If this is your final answer to the problem space, I am done testing,
> and as far as _I_ am concerned, your scheduler is an utter failure.
>
Sorry, I haven't really been following this thread and now I'm confused.
You're saying that it's somehow the
assed to a varargs function on 64-bit platforms.
(This just works in C because C makes NULL ((void*)0) is thus is the
right size. In C++, the 0 ends up being an int instead of a pointer when
passed to a varargs function, and things tend to blow up when they read
the garbage high bits. Of course, no
On Sun, 2007-03-11 at 16:50 -0700, Nicholas Miell wrote:
> You should probably make it behave like the other things that use
> itimerspec, just to avoid confusion -- i.e. timers are relative by
> default, there's a flag that makes them absolute, they expire when
> it_value spec
timerspec, just to avoid confusion -- i.e. timers are relative by
default, there's a flag that makes them absolute, they expire when
it_value specifies, and repeat every it_interval nanoseconds if
it_interval is non-zero.
i.e.
int timerfd(int ufd, int clockid, int flags, const struct timespec
On Sat, 2007-03-10 at 21:31 -0800, Linus Torvalds wrote:
>
> On Sat, 10 Mar 2007, Nicholas Miell wrote:
> >
> > Ah, I see. You're just interested in fds as a generic handle concept,
> > and not a more Plan 9 type thing.
>
> Indeed. It's a "handle&quo
On Sat, 2007-03-10 at 17:57 -0800, Davide Libenzi wrote:
> On Sat, 10 Mar 2007, Nicholas Miell wrote:
>
> > If that's the goal, somebody should start thinking about reducing the
> > contents of struct file to the bare minimum (i.e. not much more than a
> > file_ope
On Sat, 2007-03-10 at 16:35 -0800, Linus Torvalds wrote:
>
> On Sat, 10 Mar 2007, Nicholas Miell wrote:
> > >
> > > I'd actually much rather do POSIX timers the other way around: associate
> > > a
> > > generic notification mechanism with
On Sat, 2007-03-10 at 14:42 -0800, Linus Torvalds wrote:
>
> On Sat, 10 Mar 2007, Nicholas Miell wrote:
> >
> > Care to elaborate on why they're a horrible crock?
>
> It's a *classic* case of an interface that tries to do everything under
> the sun.
>
On Sat, 2007-03-10 at 13:44 -0800, Linus Torvalds wrote:
>
> On Sat, 10 Mar 2007, Nicholas Miell wrote:
> >
> > That's what the sigevent structure is for -- to describe how events
> > should be signaled to userspace, whether by signal delivery, thread
> > creat
On Sat, 2007-03-10 at 12:41 -0800, Davide Libenzi wrote:
> On Sat, 10 Mar 2007, Nicholas Miell wrote:
>
> > Try reading the timer_create man page.
> >
> > In short, you're limited to a single clock, so you can't set timers
> > based on wall-clock time (su
On Fri, 2007-03-09 at 23:36 -0800, Davide Libenzi wrote:
> On Fri, 9 Mar 2007, Nicholas Miell wrote:
>
> > On Fri, 2007-03-09 at 22:53 -0800, Davide Libenzi wrote:
> > > On Fri, 9 Mar 2007, Nicholas Miell wrote:
> > > >
> > > > So extend the existing
On Fri, 2007-03-09 at 22:53 -0800, Davide Libenzi wrote:
> On Fri, 9 Mar 2007, Nicholas Miell wrote:
>
> > On Fri, 2007-03-09 at 22:38 -0800, Davide Libenzi wrote:
> > > On Fri, 9 Mar 2007, Nicholas Miell wrote:
> > >
> > > > Why did you ignore the
On Fri, 2007-03-09 at 22:38 -0800, Davide Libenzi wrote:
> On Fri, 9 Mar 2007, Nicholas Miell wrote:
>
> > Why did you ignore the existing POSIX timer API?
>
> The existing POSIX API is a standard and a very good one. Too bad it does
> not deliver to files. The timerf
call
> to read(2). The read(2) call supportes the O_NONBLOCK flag too, and EAGAIN
> will be returned if no ticks happened.
> A quick test program, shows timerfd working correctly on my amd64 box:
>
> http://www.xmailserver.org/timerfd-test.c
>
Why did you ignore the ex
ns of thousands of tasks and scale very well
> with lots of CPUs (eg: solaris). So there is a real challenge here to try to
> provide something at least as good and universal because we know that it can
> exist. And this is what you finally did : work on a scheduler which ought to
>
On Fri, 2007-03-02 at 16:52 -0800, Davide Libenzi wrote:
> On Fri, 2 Mar 2007, Nicholas Miell wrote:
>
> > The point Ingo was making is that the x86 ABI already requires the FPU
> > context to be saved before *all* function calls.
>
> I've not seen that among Ingo&#
BIs
specs I have laying around, AMD64, PPC64, and MIPS require at least part
of the FPU state to be preserved across function calls, and I'm sure
this is also true of others.
Then there's the other nasty details of new thread creation --
thankfully, the contents of the TLS isn't inh
ignal delivery, though. (And I
suspect this bug has probably been copied to other architectures as
well.)
--
Nicholas Miell <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
false macros, you should probably
use the official all-lowercase C99 version.
--
Nicholas Miell <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.or
urrnt Linux
> kernels that the dcache/icache is precious, and that it's way too eager
> to dump dcache and icache in favour of data blocks. If I could do that,
> this problem would be much, much smaller.
>
> -hpa
Isn't setting the vm.vfs_cache_pressure sysctl below
n, so it should be doing this no matter what), and inlining
hpet_readl into wait_hpet_tick (otherwise, it can't possibly make any
assumptions about the return values of hpet_readl -- this looks to be a
SUSE-specific over-aggressive optimization), and somewhere along the way
the volatile quali
rt_cmp_val = hpet_readl(HPET_T0_CMP);
> do {
When you examine the inlined functions involved, this looks an awful lot
like http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
Perhaps SUSE should fix their gcc instead of working around compiler
problems in the kernel?
--
Nicholas Miell <
On Sun, 2005-08-07 at 12:49 +0100, Alan Cox wrote:
> On Sad, 2005-08-06 at 20:52 -0700, Nicholas Miell wrote:
> > Why does overcommit in mode 2 (OVERCOMMIT_NEVER) explicitly force
> > MAP_NORESERVE mappings to reserve memory?
> >
> > My understanding is that MAP_NOR
them.
Failing to do this makes certain well-know apps (*cough* Sun Java
*cough*) fail to run, which seems to be rather unhelpful.
--
Nicholas Miell <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROT
On Wed, 2005-08-03 at 11:03 +0200, Andi Kleen wrote:
> On Wed, Jul 27, 2005 at 11:53:30PM -0700, Nicholas Miell wrote:
> > debug.exception-trace causes a large amount of log spew when on, and
> > it's on by default, which is an irritation.
>
> > Here's a patch
7-27 23:46:10.0
-0700
@@ -284,7 +284,7 @@
}
int page_fault_trace = 0;
-int exception_trace = 1;
+int exception_trace = 0;
/*
* This routine handles page faults. It determines the address,
--
Nicholas Miell <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "uns
or debugging interfaces from other
operating systems, could we steal from Solaris instead of anything
ptrace-based?
--
Nicholas Miell <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordom
Christian Gennerat wrote:
>
> About Standard aliases:
> > modprobe -c
> ...
> alias ppp-compress-21 bsd_comp
> ...
>
> Why bsd_comp is the standard alias?
> /src/linux/Configure.help says that
>
> The PPP Deflate compression method ("PPP Deflate compression",
> above) is preferable to BSD-Com
58 matches
Mail list logo
