On Thu, 26 Mar 2015, David Rientjes wrote:
> Yes, this munmap() behavior of lengths <= hugepage_size - PAGE_SIZE for a
> hugetlb vma is long standing and there may be applications that break as a
> result of changing the behavior: a database that reserves all allocated
> hugetlb memory with mma
On Wed, 25 Mar 2015, David Rientjes wrote:
> I looked at this thread at http://marc.info/?t=14139250881 since I
> didn't have it in my mailbox, and I didn't get a chance to actually run
> your test code.
>
> In short, I think what you're saying is that
>
> ptr = mmap(..., 4KB, ..., M
On Wed, 25 Mar 2015, Hugh Dickins wrote:
> When you say "tracking back to 3.2.x", I think you mean you've tried as
> far back as 3.2.x and found the same behaviour, but not tried further?
>
> From the source, it looks like this is unchanged since MAP_HUGETLB was
> introduced in 2.6.32. And is th
tinkering).
Signed-Off-By: Davide Libenzi
- Davide
diff --git a/mm/mmap.c b/mm/mmap.c
index 7f85520..6dba257 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2528,10 +2528,6 @@ int do_munmap(struct mm_struct *mm, unsigned long start,
size_t len)
if ((start & ~PAGE_MASK) || s
On Tue, 21 Oct 2014, Davide Libenzi wrote:
> Calling mmap with MAP_HUGETLB and a size which is not 2MB aligned, causes
> mmap to fail. Tested on 3.13.x but tracking back to 3.2.x.
A couple of "un" were found under my desk, as it's clearly munmap which is
failing.
- David
result in EINVAL.
Tentative (untested) patch and test case attached (be sure you have a few
huge pages available via /proc/sys/vm/nr_hugepages tinkering).
Signed-Off-By: Davide Libenzi
- Davide
diff --git a/mm/mmap.c b/mm/mmap.c
index 7f85520..6dba257 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
On Tue, 26 Feb 2008, Michael Kerrisk wrote:
> Okay -- I'll look at it some more. I am however loathe to drop the
> term open file description, because POSIX uses, as well as a number of
> other Linux man pages by now.
Heh, POSIX. Now doesn't take a genius to see that "file description" and
"fil
On Tue, 26 Feb 2008, Michael Kerrisk wrote:
> Following up after quite some time:
>
> Davide Libenzi wrote:
> > On Sat, 26 Jan 2008, Michael Kerrisk wrote:
> >
> >> On Jan 25, 2008 12:57 AM, Davide Libenzi <[EMAIL PROTECTED]> wrote:
> >>
On Tue, 26 Feb 2008, Michael Kerrisk wrote:
> Davide Libenzi wrote:
> > On Sun, 28 Oct 2007, David Schwartz wrote:
> >
> >> Eric Dumazet wrote:
> >>
> >>> Events are not necessarly reported "by descriptors". epoll uses an opaque
> >&
rt is going to overwrite the node data. In any case I think it's
better to not have that happening at all, and fix it by simplifying the
code to get rid of a few lines that became superfluous after the previous
epoll changes.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
-
On Mon, 11 Feb 2008, Andrew Morton wrote:
> On Sun, 10 Feb 2008 13:32:01 -0800 (PST)
> Davide Libenzi <[EMAIL PROTECTED]> wrote:
>
> > Epoll calls rb_set_parent(n, n) to initialize the rb-tree node, but
> > rb_set_parent() accesses node's pointer in its code
rt is going to overwrite the node data. In any case I think it's
better to not have that happening at all, and fix it by properly
initializing the data.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
---
fs/eventpoll.c |2 +-
include/linux/rbtree.h | 12 +
On Thu, 24 Jan 2008, Pierre Habouzit wrote:
> On Fri, Jan 18, 2008 at 09:10:18PM +0000, Davide Libenzi wrote:
> > On Fri, 18 Jan 2008, Pierre Habouzit wrote:
> >
> > > Hi,
> > >
> > > I just came across a strange behavior of epoll that seems to
&
inst Fedora's 2.6.23-0.222.rc9.git4.fc8, filed in
> > October: https://bugzilla.redhat.com/show_bug.cgi?id=323411
>
> Upstream bug: http://bugzilla.kernel.org/show_bug.cgi?id=9786
>
> Date: Sun, 13 Jan 2008 19:44:26 +0100
> From: Peter Zijlstra <[EMAIL PROTECTED]>
On Tue, 22 Jan 2008, Stefan Richter wrote:
> (adding Cc: Davide and akpm)
>
> On 22 Jan, Peter Zijlstra wrote:
> >
> > On Tue, 2008-01-22 at 17:23 +0100, Stefan Richter wrote:
> >> Denys Fedoryshchenko wrote:
> >> > No, i am using vanilla kernel. It is one of production machines, and as
> >> >
On Fri, 18 Jan 2008, Pierre Habouzit wrote:
> Hi,
>
> I just came across a strange behavior of epoll that seems to
> contradict the documentation. Here is what happens:
>
> * I have two processes P1 and P2, P1 accept()s connections, and send the
> resulting file descriptors to P2 through a
On Thu, 10 Jan 2008, Rusty Russell wrote:
> On Thursday 10 January 2008 05:16:57 Zach Brown wrote:
> > > The latter. A ring is optimal for processing a huge number of requests,
> > > but if you're really going to be firing off syslet threads all over the
> > > place you're not going to be optimal
On Tue, 8 Jan 2008, Eric Dumazet wrote:
> Changli Gao a écrit :
> > Replace the epitem rbtree with a dynamic array to get the constant
> > insertion/deletion/modification time of the file descriptors. Reuse the
> > size argument of epoll_create, however the size must be smaller than the
> > max
On Sun, 6 Jan 2008, Christian Kujau wrote:
> On Sat, 5 Jan 2008, Davide Libenzi wrote:
> > A solution may be to move the call to ep_poll_safewake() (that'd become a
> > simple wake_up()) inside a tasklet or whatever is today trendy for delayed
> > work. But his kinda sca
On Sat, 5 Jan 2008, Peter Zijlstra wrote:
>
> On Sat, 2008-01-05 at 17:53 +0100, Peter Zijlstra wrote:
> > On Sat, 2008-01-05 at 18:12 +1100, Herbert Xu wrote:
> > > On Fri, Jan 04, 2008 at 09:30:49AM +0100, Ingo Molnar wrote:
> > > >
> > > > > > [ 1310.670986] ===
Make the returned time to be the remaining time till the next expiration.
If the timer is already expired, and there's no next expiration, zero will
be returned.
Andrew, this goes on top of the ones you already have in -mm.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- David
() ticks
calculation, ktime_divns(), was already having the result in u64 and it was
chopping it to unsigned long.
Andrew, this goes on top of the ones you already have in -mm.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
---
fs/timerfd.c|6 +++---
include
On Mon, 17 Dec 2007, Michael Kerrisk wrote:
> > Can you try the two patches below? I tried them on my 32 bit box (one of
> > the rare beasts still lingering around here) and it seems to be working
> > fine (those go on top of the previous ones).
>
> Against 2.6.24-rc5, I applied first your earlie
On Fri, 14 Dec 2007, Michael Kerrisk wrote:
> You snipped my example that demonstrated the problem. Both of the
> following runs create a timer that expires 10 seconds from "now", but
> observe the difference in the value returned by timerfd_gettime():
>
> $ ./timerfd_test 10 # does not
On Thu, 13 Dec 2007, Michael Kerrisk wrote:
> > > BUG 2:
> > > The last sentence does not match the implementation.
> > > (Nor is it consistent with the behavior of POSIX timers.
> > > And I *think* things did work correctly in the original
> > > timerfd() implementation, but I have not gone back
On Thu, 13 Dec 2007, Michael Kerrisk wrote:
> Davide, Andrew,
>
> I applied Davide's v3 patchset (sent into LKML on 25 Nov) against
> 2.4.24-rc3, and did various tests (all on x86). Several tests
> were done using the program at the foot of this mail. Various others
> were done by cobbling toge
On Thu, 6 Dec 2007, Oleg Nesterov wrote:
> The previous bugfix was not optimal, we shouldn't care about group stop when
> we are the only thread or the group stop is in progress. In that case nothing
> special is needed, just set PF_EXITING and return.
>
> Also, take the related "TIF_SIGPENDING r
h how much this change costs?
Anyway, looks sane to me...
Acked-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
--
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/
Update sys_ni.c with the new timerfd syscalls.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
---
kernel/sys_ni.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: linux-2.6.mod/kernel/sy
On Wed, 28 Nov 2007, Andrew Morton wrote:
> On Wed, 28 Nov 2007 14:32:07 +0100 Arnd Bergmann <[EMAIL PROTECTED]> wrote:
>
> > On Wednesday 28 November 2007, Kamalesh Babulal wrote:
> > > Kernel build fails, with build error
> > >
> > > CC arch/powerpc/platforms/cell/spu_callbacks.o
> > >
On Tue, 27 Nov 2007, Andrew Morton wrote:
> On Tue, 27 Nov 2007 12:47:46 -0800 (PST)
> Davide Libenzi <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 27 Nov 2007, Andrew Morton wrote:
> >
> > > On Sun, 25 Nov 2007 14:14:19 -0800 Davide Libenzi <[EMAIL PROTECTED
On Tue, 27 Nov 2007, Andrew Morton wrote:
> On Sun, 25 Nov 2007 14:14:19 -0800 Davide Libenzi <[EMAIL PROTECTED]> wrote:
>
> > +static struct file *timerfd_fget(int fd)
> > +{
> > + struct file *file;
> > +
> > + file = fget(fd);
> > +
On Mon, 26 Nov 2007, H. Peter Anvin wrote:
> Ingo Molnar wrote:
> >
> > So it's not like sys_indirect() would break some magic pristine state of a
> > flat parameter space - on the contrary, most of the nontrivial syscalls take
> > pointers to structures or pointers to streams of information. The
Wires up the new timerfd API to the x86 family.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
---
arch/x86/ia32/ia32entry.S |4 +++-
arch/x86/kernel/syscall_table_32.S |4 +++-
include/asm-x86/unistd_32.h|6 --
include/asm-x86/unist
Remove the broken status to CONFIG_TIMERFD.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
---
init/Kconfig |1 -
1 file changed, 1 deletion(-)
Index: linux-2.6.mod/init/Kconfig
===
--- linux-2.6.mod.ori
I think that advancing the timer against the timer's current "now" can
be a pretty common usage, so, w/out exposing hrtimer's internals, we add
a new hrtimer_forward_now() function.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
---
include/linux/h
s not been set yet.
Like the previous timerfd API implementation, read(2) and poll(2) are supported
(with the same interface).
Here's a simple test program I used to exercise the new timerfd APIs:
http://www.xmailserver.org/timerfd-test2.c
Signed-off-by: Davide Libenzi <[EMAIL PROTECTE
On Sat, 24 Nov 2007, Michael Kerrisk wrote:
> > +asmlinkage long sys_timerfd_create(int clockid, int flags)
> > {
> > - int error;
> > + int error, ufd;
> > struct timerfd_ctx *ctx;
> > struct file *file;
> > struct inode *inode;
> > - struct itimerspec ktmr;
> > -
> > - if (c
Remove the broken status to CONFIG_TIMERFD.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
---
init/Kconfig |1 -
1 file changed, 1 deletion(-)
Index: linux-2.6.mod/init/Kconfig
===
--- linux-2.6.mod.ori
Wires up the new timerfd API to the x86 family.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
---
arch/x86/ia32/ia32entry.S |4 +++-
arch/x86/kernel/syscall_table_32.S |4 +++-
include/asm-x86/unistd_32.h|6 --
include/asm-x86/unist
I think that advancing the timer against the timer's current "now" can
be a pretty common usage, so, w/out exposing hrtimer's internals, we add
a new hrtimer_forward_now() function.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
---
include/linux/h
s not been set yet.
Like the previous timerfd API implementation, read(2) and poll(2) are supported
(with the same interface).
Here's a simple test program I used to exercise the new timerfd APIs:
http://www.xmailserver.org/timerfd-test2.c
Signed-off-by: Davide Libenzi <[EMAIL PROTECTE
On Fri, 23 Nov 2007, Ulrich Drepper wrote:
> On Nov 23, 2007 9:29 AM, Davide Libenzi <[EMAIL PROTECTED]> wrote:
> > Yes, it's disabled, and yes, I'll repost today ...
>
> I haven't seen the patch and don't feel like searching. So I say it
> here: plea
On Fri, 23 Nov 2007, Andrew Morton wrote:
> > I suppose this means that timerfd will only go in for 2.6.25. I don't
> > have a problem with that, but we better make sure that the existing
> > timerfd in 2.6.24 is still disabled. (Andrew had a one liner for
> > that, but I haven't checked if it's
On Thu, 22 Nov 2007, Andrew Morton wrote:
> On Thu, 22 Nov 2007 11:46:13 -0800 (PST) Davide Libenzi <[EMAIL PROTECTED]>
> wrote:
>
> > On Thu, 22 Nov 2007, Michael Kerrisk wrote:
> >
> > > On Nov 22, 2007 6:34 PM, Davide Libenzi <[EMAIL PROTECTED]> w
On Thu, 22 Nov 2007, Michael Kerrisk wrote:
> On Nov 22, 2007 6:34 PM, Davide Libenzi <[EMAIL PROTECTED]> wrote:
> > On Thu, 22 Nov 2007, Michael Kerrisk wrote:
> >
> > > Hey Davide,
> > >
> > > Where is the new timerfd API. In 2.6.24-rc3, I see t
On Thu, 22 Nov 2007, Michael Kerrisk wrote:
> Hey Davide,
>
> Where is the new timerfd API. In 2.6.24-rc3, I see the *old* API...
Maybe Andrew stuffed the turkey with it? :) It was there. I remeber it was
merged. Some screw up reverted it?
- Davide
-
To unsubscribe from this list: send the
On Tue, 20 Nov 2007, Ingo Molnar wrote:
> * H. Peter Anvin <[EMAIL PROTECTED]> wrote:
>
> > It seems that you're doing the same thing in both cases, except you're
> > now extending it to include other random functionality, which means
> > other things than syslets are suddenly affected.
> >
> >
On Sun, 28 Oct 2007, David Schwartz wrote:
>
> Eric Dumazet wrote:
>
> > Events are not necessarly reported "by descriptors". epoll uses an opaque
> > field provided by the user.
> >
> > It's up to the user to properly chose a tag that will makes sense
> > if the user
> > app is playing dup()/cl
On Sat, 27 Oct 2007, David Schwartz wrote:
> I don't see how that can be. Suppose I add fd 8 to an epoll set.
> Suppose fd
> 5 is a dup of fd 8. Now, I close fd 8. How can fd 8 remain in my epoll set,
> since there no longer is an fd 8? Events on files registered for epoll
> notification ar
On Sat, 27 Oct 2007, Willy Tarreau wrote:
> On Sat, Oct 27, 2007 at 09:59:07AM -0700, Davide Libenzi wrote:
> > On Sat, 27 Oct 2007, Marc Lehmann wrote:
> >
> > > > Please provide some code to illustrate one exact problem you have.
> > >
> > >
On Sat, 27 Oct 2007, Marc Lehmann wrote:
> > Please provide some code to illustrate one exact problem you have.
>
>// assume there is an open epoll set that listens for events on fd 5
>if (fork () = 0)
> {
>close (5);
>// fd 5 is now removed from the epoll set of the
On Wed, 17 Oct 2007, Michael Kerrisk wrote:
> > With the new code Linus already merged, signalfd does not attach to the
> > sighand anymore, so the "orphaned sighand" behaviour is no more there.
> > An exec() will carry the fd over, and you will be able to use the fd in
> > the same way you did
On Mon, 15 Oct 2007, Michael Kerrisk wrote:
> Hi Davide,
>
> There were two questions that you overlooked in my earlier draft of the
> signalfd man page. I've revised one of the questions slightly. Could you
> look at these please:
I think I already answered those, no? Anyway ...
> .SS exec
On Tue, 2 Oct 2007, Denys Vlasenko wrote:
> I have following proposals:
>
> * make recv(..., MSG_DONTWAIT) work on any fd
>
> Sounds neat, but not trivial to implement in current kernel.
This is mildly ugly, if you ask me. Those are socket functions, and the
flags parameter contain some pretty
On Mon, 1 Oct 2007, Paul E. McKenney wrote:
> That would indeed be one approach that CPU designers could take to
> avoid being careless or sadistic. ;-)
That'd be the easier (unique maybe) approach too for them, from an silicon
complexity POV. Distinguishing between different CPUs stores once i
On Mon, 1 Oct 2007, Denys Vlasenko wrote:
> On Monday 01 October 2007 19:16, Al Viro wrote:
> > * it's on a bunch of cyclic lists. Have its neighbor
> > go away while you are doing all that crap => boom
> > * there's that thing call current position... It gets buggered.
> > * overwri
On Sun, 30 Sep 2007, Paul E. McKenney wrote:
> On Sun, Sep 30, 2007 at 04:02:09PM -0700, Davide Libenzi wrote:
> > On Sun, 30 Sep 2007, Oleg Nesterov wrote:
> >
> > > Ah, but I asked the different question. We must see CPU 1's stores by
> > > definition
On Mon, 1 Oct 2007, Denys Vlasenko wrote:
> My use case is: I want to do a nonblocking read on descriptor 0 (stdin).
> It may be a pipe or a socket.
>
> There may be other processes which share this descriptor with me,
> I simply cannot know that. And they, too, may want to do reads on it.
>
> I
On Sun, 30 Sep 2007, Denys Vlasenko wrote:
> Hi Ulrich,
>
> On Friday 28 September 2007 18:34, Ulrich Drepper wrote:
> > One more small change to extend the availability of creation of
> > file descriptors with FD_CLOEXEC set. Adding a new command to
> > fcntl() requires no new system call and t
On Sun, 30 Sep 2007, Oleg Nesterov wrote:
> Ah, but I asked the different question. We must see CPU 1's stores by
> definition, but what about CPU 0's stores (which could be seen by CPU 1)?
>
> Let's take a "real life" example,
>
> A = B = X = 0;
> P = Q = &A;
>
On Sat, 29 Sep 2007, Nick Piggin wrote:
> [ This is true for x86's sfence/lfence, but raises a question about Linux's
> memory barriers. Does anybody expect that a sequence of smp_wmb and smp_rmb
> would ever provide a full smp_mb barrier? I've always assumed no, but I
> don't know if it is actual
On Fri, 28 Sep 2007, Ulrich Drepper wrote:
> One more small change to extend the availability of creation of
> file descriptors with FD_CLOEXEC set. Adding a new command to
> fcntl() requires no new system call and the overall impact on
> code size if minimal.
>
> If this patch gets accepted we
Since we know the shared inode count is always >0, we can avoid igrab()
and use an open coded atomic_inc().
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
---
fs/anon_inodes.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
Index:
For Michael Kerrisk request, the following patch renames signalfd_siginfo
fields in order to keep them consistent with the siginfo_t ones.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
---
fs/signalfd.c| 44 ++--
i
On Thu, 27 Sep 2007, Michael Kerrisk wrote:
> .\" Copyright (C) 2007 Michael Kerrisk <[EMAIL PROTECTED]>
> .\" starting from a version by Davide Libenzi <[EMAIL PROTECTED]>
> .\"
> .\" This program is free software; you can redistribute it and/or modify
On Thu, 27 Sep 2007, Michael Kerrisk wrote:
> Hi Davide,
>
> I've slightly tweaked the eventfd.2 man page in preparation for adding it
> to the man-pages set. Could you please review the text below, and confirm
> that it correctly describes intended behavior.
Looks good to me. At the time that
On Thu, 27 Sep 2007, Michael Kerrisk wrote:
> Davide,
>
> A further question: what is the expected behavior in the
> following scenario:
>
> 1. Create a timerfd and arm it.
> 2. Wait until M timer expirations have occurred
> 3. Modify the settings of the timer
> 4. Wait for N further timer expir
On Thu, 27 Sep 2007, Michael Kerrisk wrote:
> Hi Davide,
>
> A follow up to the man page text. Does passing a timerfd file
> descriptor via a Unix domain socket to another process do the
> expected thing? That is, the receiving process will be able to
> read from the file descriptor in order t
Michael, SCB ...
On Wed, 26 Sep 2007, Michael Kerrisk wrote:
> .TH TIMERFD_CREATE 2 2007-09-26 Linux "Linux Programmer's Manual"
> .SH NAME
> timerfd_create, timerfd_settime, timer_gettime \-
> timers that notify via file descriptors
> .SH SYNOPSIS
> .\" FIXME . This header file may well change
On Tue, 25 Sep 2007, Jonathan Corbet wrote:
> One quick question:
>
> > Like the previous timerfd API implementation, read(2) and poll(2) are
> > supported
> > (with the same interface).
>
> Looking at that interface, it appears that a process doing a read() on a
> timerfd with no timer set wil
On Tue, 25 Sep 2007, roel wrote:
> > + if (!(ap->flags & ATA_FLAG_IPM) || !ata_dev_enabled(dev)) {
>
> if (!((ap->flags & ATA_FLAG_IPM) && ata_dev_enabled(dev))) {
int foo(int i, int j) {
return !(i & 8) || !j;
}
int moo(int i, int j) {
return !((i & 8)
Remove the broken status to CONFIG_TIMERFD.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
---
init/Kconfig |1 -
1 file changed, 1 deletion(-)
Index: linux-2.6.mod/init/Kconfig
===
--- linux-2.6.mod.ori
t been set yet.
Like the previous timerfd API implementation, read(2) and poll(2) are supported
(with the same interface).
Here's a simple test program I used to exercise the new timerfd APIs:
http://www.xmailserver.org/timerfd-test2.c
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- D
Wires up the new timerfd API to the x86 family.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
---
arch/i386/kernel/syscall_table.S |5 -
arch/x86_64/ia32/ia32entry.S |4 +++-
include/asm-i386/unistd.h|6 --
include/asm-x86_64/un
I think that advancing the timer against the timer's current "now" can
be a pretty common usage, so, w/out exposing hrtimer's internals, we add
a new hrtimer_forward_now() function.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
---
include/linux/h
On Mon, 24 Sep 2007, Michael Kerrisk wrote:
> Hi Davide,
>
> Davide Libenzi wrote:
> > On Mon, 24 Sep 2007, Michael Kerrisk wrote:
> >> Is it perhaps not better to group the three syscalls contiguously with
> >> respect to syscall numbers? The old timerfd slot c
On Mon, 24 Sep 2007, Thomas Gleixner wrote:
> > struct timerfd_ctx {
> > struct hrtimer tmr;
> > + int clockid;
> > ktime_t tintv;
> > wait_queue_head_t wqh;
> > int expired;
> > + u64 ticks;
> > };
>
> Can you please restructure the struct in a way which does not result in
On Mon, 24 Sep 2007, Michael Kerrisk wrote:
> Davide,
>
> Is it perhaps not better to group the three syscalls contiguously with
> respect to syscall numbers? The old timerfd slot can be re-used for some
> other syscall later.
There's no problem if they're not contiguous. Holes, unless filled
Remove the broken status to CONFIG_TIMERFD.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
---
init/Kconfig |1 -
1 file changed, 1 deletion(-)
Index: linux-2.6.mod/init/Kconfig
===
--- linux-2.6.mod.ori
t been set yet.
Like the previous timerfd API implementation, read(2) and poll(2) are supported
(with the same interface).
Here's a simple test program I used to exercise the new timerfd APIs:
http://www.xmailserver.org/timerfd-test2.c
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- D
Wires up the new timerfd API to the x86 family.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
---
arch/i386/kernel/syscall_table.S |5 -
arch/x86_64/ia32/ia32entry.S |4 +++-
include/asm-i386/unistd.h|6 --
include/asm-x86_64/un
On Sun, 23 Sep 2007, Davide Libenzi wrote:
> On Sun, 23 Sep 2007, Michael Kerrisk wrote:
>
> > I applied this patch against 2.6.27-rc7, and wired up the syscalls as shown
> > in the definitions below. When I ran the the program below, my system
> > immediately froze.
On Sun, 23 Sep 2007, Michael Kerrisk wrote:
> I applied this patch against 2.6.27-rc7, and wired up the syscalls as shown
> in the definitions below. When I ran the the program below, my system
> immediately froze. Can you try it on your system please.
There's an hrtimer_init() missing in timer
On Sat, 22 Sep 2007, Thomas Gleixner wrote:
> On Sat, 2007-09-22 at 14:07 -0700, Davide Libenzi wrote:
> > On Sat, 22 Sep 2007, Michael Kerrisk wrote:
> >
> > > So I'm inclined to implement option (b), unless someone has strong
> > > objections. Davide, co
On Sat, 22 Sep 2007, Michael Kerrisk wrote:
> So I'm inclined to implement option (b), unless someone has strong
> objections. Davide, could I persuade you to help?
I guess I better do, otherwise you'll continue to stress me ;)
int timerfd_create(int clockid);
int timerfd_settime(int ufd, int f
On Thu, 20 Sep 2007, Nagendra Tomar wrote:
> > That's not what POLLOUT means in the Unix meaning. POLLOUT indicates the
> > ability to write, and it is not meant as to signal every time a packet
> > (skb) is sent on the wire (and the buffer released).
>
> Aren't they both the same ? Everytime a
On Thu, 20 Sep 2007, Nagendra Tomar wrote:
>
> --- Davide Libenzi <[EMAIL PROTECTED]> wrote:
>
> > Looking back at it, I think the current TCP code is right, once you look
> > at the "event" to be a output buffer full->with_space transition.
> >
d eventually issue the real wakeup).
But it won't work for epoll, since it already expect to install its own
callback, and ATM callbacks can't be chained.
Since the thundering herd effect on signalfds should be pretty limited, I
think it's not worth the change.
Signed-off-by: Davide
On Thu, 20 Sep 2007, Eric Dumazet wrote:
> Does it means that with your patch each ACK on a ET managed socket will
> trigger an epoll event ?
>
> Maybe your very sensitive high throuput appication needs to set a flag or
> something at socket level to ask for such a behavior.
>
> The default sh
On Wed, 19 Sep 2007, Nagendra Tomar wrote:
> The tcp_check_space() function calls tcp_new_space() only if the
> SOCK_NOSPACE bit is set in the socket flags. This is causing Edge Triggered
> EPOLLOUT events to be missed for TCP sockets, as the ep_poll_callback()
> is not called from the wakeup rou
On Wed, 19 Sep 2007, Nagendra Tomar wrote:
> Definitely not !
>
> The point is that the "tcp write space available"
> wakeup does not get called if SOCK_NOSPACE bit is not set. This was
> fine when the wakeup was merely a wakeup (since SOCK_NOSPACE bit
> indicated that someone really cared abt
On Wed, 19 Sep 2007, David Miller wrote:
> From: Nagendra Tomar <[EMAIL PROTECTED]>
> Date: Wed, 19 Sep 2007 15:37:09 -0700 (PDT)
>
> > With the SOCK_NOSPACE check in tcp_check_space(), this epoll_wait call will
> > not return, even when the incoming acks free the buffers.
> > Note that
On Wed, 19 Sep 2007, Nagendra Tomar wrote:
[ ... ]
Seems like epoll ate your message too :)
Can you repost your bug report and the patch?
- Davide
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at ht
On Tue, 18 Sep 2007, Michael Kerrisk wrote:
> The four designs are:
>
> a) A multiplexing timerfd() system call.
> b) Creating three syscalls analogous to the POSIX timers API (i.e.,
>timerfd_create/timerfd_settime/timerfd_gettime).
> c) Creating a simplified timerfd() system call that is int
On Thu, 6 Sep 2007, Michael Kerrisk wrote:
> You are asserting this in the face of two previous APIs designed
> by people who (at least in the case of POSIX timers) probably
> thoroughly examined and discussed existing APIs and practice.
You really think that. Uhmm, ok.
> This function is *n
On Thu, 6 Sep 2007, Michael Kerrisk wrote:
> Hi Davide,
>
> > > > > > > As I think about this more, I see more problems with
> > > > > > > your argument. timerfd needs the ability to get and
> > > > > > > get-while-setting just as much as the earlier APIs.
> > > > > > > Consider a library that
On Wed, 5 Sep 2007, Michael Kerrisk wrote:
> Hi Davide,
>
> > > > > As I think about this more, I see more problems with
> > > > > your argument. timerfd needs the ability to get and
> > > > > get-while-setting just as much as the earlier APIs.
> > > > > Consider a library that creates a timerf
On Wed, 5 Sep 2007, Michael Kerrisk wrote:
> Davide,
A Michael!
> > > As I think about this more, I see more problems with
> > > your argument. timerfd needs the ability to get and
> > > get-while-setting just as much as the earlier APIs.
> > > Consider a library that creates a timerfd file d
On Tue, 4 Sep 2007, Michael Kerrisk wrote:
> > Useless like it'd be a motorcycle w/out a cup-holder :)
> > Seriously, the ability to get the previous values from "something" could
> > have a meaning if this something is a shared global resource (like
> > signals
> > for example). In the timerfd
1 - 100 of 765 matches
Mail list logo
