- ---
16 18.7404.603 1.455
I remeber the O(1) scheduler from Davide Libenzi was beating the
mainline O(N)
isn't the normal case (as in "The Right Case to optimize"
by Davide Libenzi [EMAIL PROTECTED]
You can do whatever you want with this program, but I'm not
responsible for any misuse. Be aware that it can heavily load
a host. As it is multithreaded, it might take advantages of SMP.
It basically creates a growing amount of threads and measures
On Friday 19 January 2001 07:59, Bill Hartner wrote:
Just a couple of notes on the sched_test_yield benchmark.
I posted it to the mailing list in Dec. I have a todo to get
a home for it. There are some issues though. See below.
(1) Beware of the changes in sys_sched_yield() for 2.4.0.
On Friday 19 January 2001 13:59, Mike Kravetz wrote:
On Fri, Jan 19, 2001 at 12:49:21PM -0800, Mike Kravetz showed his lack
of internet slang understanding and wrote:
It was my intention to post IIRC numbers for small thread counts today.
However, the benchmark (not the system) seems to
On Friday 19 January 2001 15:23, Mike Kravetz wrote:
On Fri, Jan 19, 2001 at 02:03:06PM -0800, Davide Libenzi wrote:
stuff deleted
voidoneatwork(int thr)
{
int i;
while (!start) /* don't disturb pthread_create() */
usleep
On Monday 22 January 2001 08:57, Hubertus Franke wrote:
Per popular demand. Here are a few numbers for small thread counts
running the sched_yield_test benchmark on a 2-way SMP with the following
characteristics.
model name : Pentium III (Katmai)
stepping: 3
cpu MHz :
On Monday 22 January 2001 10:30, Mike Kravetz wrote:
Last week while discussing scheduler benchmarks, Bill Hartner
made a comment something like the following "the benchmark may
not even be invoking the scheduler as you expect". This comment
did not fully sink in until this weekend when I
On Tuesday 30 January 2001 08:14, Micah Gorrell wrote:
I have been running 2.2 on many machines since its release and have updated
to the latest version of 2.2 many times. All of these machines have an
eepro100 and I never saw a single problem with any of them. I updated most
of my machines
On 28-Jun-2001 Anil Kumar wrote:
hi,
How do i read file within the kernel modules. I hope we can't use the FS
open... calls within kernel.
You can access fs methods directly.
Look at this newbie article :
http://www.linux-mag.com/2000-11/gear_01.html
- Davide
-
To unsubscribe from this
On 28-May-2001 Mike Castle wrote:
On Mon, May 28, 2001 at 11:26:31AM -0700, Davide Libenzi wrote:
On 28-Jun-2001 Anil Kumar wrote:
hi,
How do i read file within the kernel modules. I hope we can't use the FS
open... calls within kernel.
You can access fs methods directly
On Sun, 10 Sep 2000, richard wrote:
I am currnetly using Redhat Linux 6.2, and am having serious difficulty
finding the "right" email tools, and as this list is often times huge,
and is also linux based, I figured some of you might be using that
tool, i have not found.
here are some of
On Sun, 10 Sep 2000, Giuliano Pochini wrote:
I need to create a "file" in /proc to monitor some kernel
variables from user space. How can I do ? / Where can I
get docs ? And how can I do time measurements from
inside the kernel ?
Search for proc_register() inside the kernel sources.
I don't
On Sun, 10 Sep 2000, Alexander Viro wrote:
On Sun, 10 Sep 2000, Davide Libenzi wrote:
On Sun, 10 Sep 2000, Giuliano Pochini wrote:
I need to create a "file" in /proc to monitor some kernel
variables from user space. How can I do ? / Where can I
get docs ? And how can
On 25-Feb-2001 Fabrice Peix wrote:
Yop,
Just a newbie question ...
Why sys_sched_yield don't call schedule ?
man page of sched_yield tell :
"A process can relinquish the processor voluntarily
without blocking by calling
On 25-Feb-2001 Tim Waugh wrote:
I'm trying to chase down a semaphore time-out problem. I want to
sleep on a semaphore until either
(a) it's signalled, or
(b) some amount of time has elapsed.
What I'm doing is calling add_timer, and then down_interruptible, and
finally del_timer. The
On 27-Feb-2001 Tim Waugh wrote:
On Tue, Feb 27, 2001 at 10:40:35PM +, Andrew Morton wrote:
1: Your code is leaving the semaphore in a down'ed state
somehow.
This was probably it. I don't know why it works for me but not some
other people though. :-/
UP vs. MP ?
- Davide
-
On 10-Mar-2001 Mike Kravetz wrote:
Any thoughts about adding a 'fast path' to the SMP code in
sys_sched_yield. Why not compare nr_pending to smp_num_cpus
before examining the aligned_data structures? Something like,
if (nr_pending smp_num_cpus)
goto set_resched_now;
Where
On 10-Mar-2001 Andi Kleen wrote:
Davide Libenzi [EMAIL PROTECTED] writes:
Probably the rate at which is called sys_sched_yield() is not so high to let
the performance improvement to be measurable.
LinuxThreads mutexes call sched_yield() when a lock is locked, so when you
have
On 11-Mar-2001 Anton Blanchard wrote:
This is the linux thread spinlock acquire :
static void __pthread_acquire(int * spinlock)
{
int cnt = 0;
struct timespec tm;
while (testandset(spinlock)) {
if (cnt MAX_SPIN_COUNT) {
sched_yield();
cnt++;
} else {
On 11-Mar-2001 Anton Blanchard wrote:
This is the linux thread spinlock acquire :
static void __pthread_acquire(int * spinlock)
{
int cnt = 0;
struct timespec tm;
while (testandset(spinlock)) {
if (cnt MAX_SPIN_COUNT) {
sched_yield();
cnt++;
} else {
On 11-Mar-2001 Dave Zarzycki wrote:
On Mon, 12 Mar 2001, Anton Blanchard wrote:
Perhaps we need something like sched_yield that takes off some of
tsk-counter so the task with the spinlock will run earlier.
Personally speaking, I wish sched_yield() API was like so:
int
On Wed, 27 Dec 2000, Rogier Wolff wrote:
Hi,
We have a typical semaphore application that has a producer and a
consumer.
Without the semaphores we are limited by the rest of the stuff to
1 times around the loop per second. That's good.
When we put the "push the semaphore" call in
On Wed, 01 Nov 2000, Jeff V. Merkey wrote:
moveax, addr
mov[addr], ebx
Probably You mean this :
mov r/imm, %eax
mov (%eax), %ebx
- Davide
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read
On Thu, 02 Nov 2000, Jeff V. Merkey wrote:
"Jeff V. Merkey" wrote:
This code fragment will generate an AGI condition:
mov eax, addr
mov [eax].offset, ebx
I had already posted the correction.
It was clear that You had forgot something coz Your old code fragment did not
generate AGI.
-
On Mon, 06 Nov 2000, Alexander Viro wrote:
On Sun, 5 Nov 2000, Anonymous wrote:
Does anyone know where to find a gui for gcc or g++ or any compiler for a
KDE shell?
Yes.
:^)
www.kdevelop.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Mon, 06 Nov 2000, George Talbot wrote:
On Fri, 3 Nov 2000, Theodore Y. Ts'o wrote:
Date:Fri, 03 Nov 2000 14:44:17 -0500
From: [EMAIL PROTECTED]
My problem is that pthread_create (glibc 2.1.3, kernel 2.2.17 i686) is
failing because, deep inside glibc somewhere,
On Tue, 07 Nov 2000, Erik Mouw wrote:
Is the kernel memory fragmentation a solved problem in Linux? (I wish it).
My guess is that the slab allocator solves this, but I don't know that
much about the MM.
Linux lists implementation stores linking informations directly inside the
block
On Fri, 10 Nov 2000, Neil W Rickert wrote:
"Jeff V. Merkey" [EMAIL PROTECTED] wrote:
The problem of dropping connections on 2.4 was related to the O RefuseLA
settings. The defaults in the RedHat, Suse, and OpenLinux RPMs are
clearly set too low for modern Linux kernels. You may want them
On 27-Apr-2001 tc lewis wrote:
i saw a few messages in the archive about these, but i'm still unclear on
the current situation.
according to /proc/pci, i'm working with a:
Bus 0, device 9, function 1:
I2O: Distributed Processing Technology SmartRAID V Controller (rev 2).
On 28-Apr-2001 Tony Hoyle wrote:
Is there a way (kernel or userspace... doesn't matter) that gdb/ddd
could be invoked when a program is about
to dump core, or perhaps on a certain signal (that the app could deliver
to itself when required). The latter case
is what I need right now, as I
On 28-Apr-2001 Tony Hoyle wrote:
On 28 Apr 2001 13:44:48 -0700, Davide Libenzi wrote:
Sorry but why don't You run Your application with gdb ?
Once Your program crashes You'll get the prompt and You'll be able to
stack-trace and watching whatever You need.
The solution I use to be able
On 29-Apr-2001 tc lewis wrote:
On Thu, 26 Apr 2001, Davide Libenzi wrote:
On 27-Apr-2001 tc lewis wrote:
i saw a few messages in the archive about these, but i'm still unclear on
the current situation.
according to /proc/pci, i'm working with a:
Bus 0, device 9, function 1
On 04-May-2001 Fabio Riccardi wrote:
ok, I'm totally ignorant here, what is a pipelined request?
http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html
QUOTE
A pipelined application implementation buffers its output before writing it to
the underlying TCP stack, roughly equivalent to
On 20-Feb-2001 Daniel Phillips wrote:
Earlier this month a runaway installation script decided to mail all its
problems to root. After a couple of hours the script aborted, having
created 65535 entries in Postfix's maildrop directory. Removing those
files took an awfully long time. The
On 21-Feb-2001 Giuliano Pochini wrote:
Perhaps this is a faq...
I have a dual-800 (mb asus, no AGP) with 1GB ram,
but according to /proc/meminfo tells I only have
90KB. I tried "mem=1024" boot parameter without
success. How can I get my 128MB back ?
Check Your BIOS setting coz some
On 21-Feb-2001 Martin Mares wrote:
Hello!
Have You tried to use skiplists ?
In 93 I've coded a skiplist based directory access for Minix and it gave
very
interesting performances.
Skiplists have a link-list like performance when linear scanned, and overall
good performance in
On 21-Feb-2001 Martin Mares wrote:
Hello!
To have O(1) you've to have the number of hash entries number of files and
a
really good hasing function.
No, if you enlarge the hash table twice (and re-hash everything) every time
the
table fills up, the load factor of the table keeps small
On 21-Feb-2001 Martin Mares wrote:
Hello!
My personal preference goes to skiplist coz it doesn't have fixed ( or
growing
) tables to handle. You've simply a stub of data togheter with FS data in
each
direntry.
Another problem with skip lists is that they require variable sized nodes,
On 21-Feb-2001 Linus Torvalds wrote:
In article [EMAIL PROTECTED],
Ed Tomlinson [EMAIL PROTECTED] wrote:
The default in reiserfs is now the R5 hash, but you are right that lots of
efforts went
into finding this hash. This includes testing various hashes on real
directory
structures to see
On 21-Feb-2001 Daniel Phillips wrote:
"H. Peter Anvin" wrote:
Martin Mares wrote:
True. Note too, though, that on a filesystem (which we are, after all,
talking about), if you assume a large linear space you have to create a
file, which means you need to multiply the cost of all
On 04-Apr-2001 Ingo Molnar wrote:
On Tue, 3 Apr 2001, Fabio Riccardi wrote:
I've spent my afternoon running some benchmarks to see if MQ patches
would degrade performance in the "normal case".
no doubt priority-queue can run almost as fast as the current scheduler.
What i'm worried
On 08-Apr-2001 Rogier Wolff wrote:
Matti Aarnio wrote:
On Sun, Apr 08, 2001 at 02:10:52PM +0900, [EMAIL PROTECTED] wrote:
How about creating an additional ML,
the new ML (say LKML-DUL) is used to send mails from DUL to LKML, but
such mails are not sent to LMKL.
Layering and
On Mon, 16 Apr 2007, Pavel Pisa wrote:
I cannot help myself to not report results with GAVL
tree algorithm there as an another race competitor.
I believe, that it is better solution for large priority
queues than RB-tree and even heap trees. It could be
disputable if the scheduler needs such
On Tue, 17 Apr 2007, Nick Piggin wrote:
All things are not equal; they all have different properties. I like
Exactly. So we have to explore those properties and evaluate performance
(in all meanings of the word). That's only logical.
I had a quick look at Ingo's code yesterday. Ingo is
On Tue, 17 Apr 2007, Nick Piggin wrote:
To be clear, I'm not saying O(logN) itself is a big problem. Type
plot [10:100] x with lines, log(x) with lines, 1 with lines
Haha, Nick, I know how a log() looks like :)
The Time Ring I posted as example (that nothing is other than a
ring-based
On Tue, 17 Apr 2007, William Lee Irwin III wrote:
On Mon, Apr 16, 2007 at 11:50:03PM -0700, Davide Libenzi wrote:
I would suggest to thoroughly test all your alternatives before deciding.
Some code and design may look very good and small at the beginning, but
when you start patching
On Tue, 17 Apr 2007, Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
ok - fortunately the delta between -v2-rc0 and -v2-final is pretty
small. One difference is the child-runs-first fix. To restore the
parent-runs-first logic, do this:
echo 0
On Tue, 17 Apr 2007, Ingo Molnar wrote:
ok - fortunately the delta between -v2-rc0 and -v2-final is pretty
small. One difference is the child-runs-first fix. To restore the
parent-runs-first logic, do this:
echo 0 /proc/sys/kernel/sched_child_runs_first
Sorry, I did not follow
. just considering the context
of the scheduler's state machine).
ISTR Davide Libenzi having a scheduling latency test a number of years
ago. Resurrecting that and tuning it to the needs of this kind of
testing sounds relevant here. The test suite Peter Willliams mentioned
would also help
On Tue, 17 Apr 2007, William Lee Irwin III wrote:
100**(1/39.0) ~= 1.12534 may do if so, but it seems a little weak, and
even 1000**(1/39.0) ~= 1.19378 still seems weak.
I suspect that in order to get low nice numbers strong enough without
making high nice numbers too strong something
On Wed, 18 Apr 2007, Matt Mackall wrote:
On Wed, Apr 18, 2007 at 07:48:21AM -0700, Linus Torvalds wrote:
And fairness by euid is probably a hell of a lot easier to do than
trying to figure out the wakeup matrix.
For the record, you actually don't need to track a whole NxN matrix
(or do
On Wed, 18 Apr 2007, William Lee Irwin III wrote:
Thinking of the scheduler as a CPU bandwidth allocator, this means
handing out shares of CPU bandwidth to all users on the system, which
in turn hand out shares of bandwidth to all sessions, which in turn
hand out shares of bandwidth to all
On Wed, 18 Apr 2007, Linus Torvalds wrote:
I'm not arguing against fairness. I'm arguing against YOUR notion of
fairness, which is obviously bogus. It is *not* fair to try to give out
CPU time evenly!
Perhaps on the rare occasion pursuing the right course demands an act of
unfairness,
On Wed, 18 Apr 2007, Linus Torvalds wrote:
For example, maybe we can approximate it by spreading out the statistics:
right now you have things like
- last_ran, wait_runtime, sum_wait_runtime..
be per-thread things. Maybe some of those can be spread out, so that you
put a part of them
On Wed, 18 Apr 2007, Ingo Molnar wrote:
That's one reason why i dont think it's necessarily a good idea to
group-schedule threads, we dont really want to do a per thread group
percpu_alloc().
I still do not have clear how much overhead this will bring into the
table, but I think (like
On Wed, 18 Apr 2007, Linus Torvalds wrote:
On Wed, 18 Apr 2007, Davide Libenzi wrote:
Perhaps on the rare occasion pursuing the right course demands an act of
unfairness, unfairness itself can be the right course?
I don't think that's the right issue.
It's just that fairness
On Thu, 19 Apr 2007, Ingo Molnar wrote:
i disagree that the user 'would expect' this. Some users might. Others
would say: 'my 10-thread rendering engine is more important than a
1-thread job because it's using 10 threads for a reason'. And the CFS
feedback so far strengthens this point:
On Thu, 19 Apr 2007, Mike Galbraith wrote:
On Thu, 2007-04-19 at 09:09 +0200, Ingo Molnar wrote:
* Mike Galbraith [EMAIL PROTECTED] wrote:
With a heavily reniced X (perfectly fine), that should indeed solve my
daily usage pattern nicely (always need godmode for shells, but not
On Thu, 8 Mar 2007, David M. Lloyd wrote:
On Wed, 2007-03-07 at 17:21 -0800, Davide Libenzi wrote:
int signalfd_dequeue(int fd, siginfo_t *info, long timeo);
The fd parameter must ba a signalfd file descriptor. The info parameter
is a pointer to the siginfo that will receive
On Thu, 8 Mar 2007, Linus Torvalds wrote:
You missed David's worry, I think.
Not only is POLLIN potentially an edge event (depending on the interface
you use to fetch it), but even as a level-triggered one you generally want
to read as much as possible per POLLIN event, and go back to the
On Thu, 8 Mar 2007, Linus Torvalds wrote:
On Thu, 8 Mar 2007, Davide Libenzi wrote:
The reason for the special function, was not to provide a non-blocking
behaviour with zero timeout (that just a side effect), but to read the
siginfo. I was all about using read(2) (and v1 used
On Thu, 8 Mar 2007, Linus Torvalds wrote:
On Thu, 8 Mar 2007, Davide Libenzi wrote:
So, to cut it short, I can do the pseudo-siginfo read(2), but I don't
like it too much (little, actually). The siginfo, as bad as it is, is a
standard used in many POSIX APIs (hence even in kernel
On Thu, 8 Mar 2007, Avi Kivity wrote:
Davide Libenzi wrote:
So, to cut it short, I can do the pseudo-siginfo read(2), but I don't like
it too much (little, actually). The siginfo, as bad as it is, is a standard
used in many POSIX APIs (hence even in kernel), and IMO if we want to send
On Thu, 8 Mar 2007, Oleg Nesterov wrote:
Davide Libenzi wrote:
+int signalfd_deliver(struct sighand_struct *sighand, int sig, struct
siginfo *info)
+{
+ int nsig = 0;
+ struct list_head *pos;
+ struct signalfd_ctx *ctx;
+ struct signalfd_sq *sq;
+
+ list_for_each
*).
This allow code reuse, and will be used by epoll, signalfd and timerfd
(and whatever else there'll be).
Signed-off-by: Davide Libenzi davidel@xmailserver.org
- Davide
Index: linux-2.6.20.ep2/fs/anon_inodes.c
===
--- /dev/null
*/
__s32 svint;/* si_int */
__u64 svptr;/* si_ptr */
__u64 utime;/* si_utime */
__u64 stime;/* si_stime */
__u64 addr; /* si_addr */
};
Signed-off-by: Davide Libenzi davidel@xmailserver.org
- Davide
Index: linux-2.6.20.ep2/fs/signalfd.c
This patch implement the necessary compat code for the signalfd system call.
Signed-off-by: Davide Libenzi davidel@xmailserver.org
- Davide
Index: linux-2.6.20.ep2/fs/compat.c
===
--- linux-2.6.20.ep2.orig/fs/compat.c 2007-03
This patch wire the signalfd system call to the i386 architecture.
Signed-off-by: Davide Libenzi davidel@xmailserver.org
- Davide
Index: linux-2.6.20.ep2/arch/i386/kernel/syscall_table.S
===
--- linux-2.6.20.ep2.orig/arch/i386
On Thu, 8 Mar 2007, Linus Torvalds wrote:
On Fri, 9 Mar 2007, Oleg Nesterov wrote:
Also. A malicious user can eat all memory,
signalfd_deliver()-kmem_cache_alloc()
doesn't check any limits.
This, btw, is one reason I *really* think signalfd() should just use the
same old
On Fri, 9 Mar 2007, Oleg Nesterov wrote:
Logic is, if it's not an RT signal, queue only one, otherwise multiple.
The bit on the -pending mask is clealer only when the queue slot becomes
empty.
Yes, I see what the code does, but I don't undestand why. For example,
SIGCHLD was
*).
This allow code reuse, and will be used by epoll, signalfd and timerfd
(and whatever else there'll be).
Signed-off-by: Davide Libenzi davidel@xmailserver.org
- Davide
Index: linux-2.6.20.ep2/fs/anon_inodes.c
===
--- /dev/null
*/
__s32 svint;/* si_int */
__u64 svptr;/* si_ptr */
__u64 utime;/* si_utime */
__u64 stime;/* si_stime */
__u64 addr; /* si_addr */
};
Signed-off-by: Davide Libenzi davidel@xmailserver.org
- Davide
Index: linux-2.6.20.ep2/fs/signalfd.c
This patch wire the signalfd system call to the i386 architecture.
Signed-off-by: Davide Libenzi davidel@xmailserver.org
- Davide
Index: linux-2.6.20.ep2/arch/i386/kernel/syscall_table.S
===
--- linux-2.6.20.ep2.orig/arch/i386
This patch wire the signalfd system call to the x86_64 architecture.
Signed-off-by: Davide Libenzi davidel@xmailserver.org
- Davide
Index: linux-2.6.20.ep2/include/asm-x86_64/unistd.h
===
--- linux-2.6.20.ep2.orig/include/asm
This patch implement the necessary compat code for the signalfd system call.
Signed-off-by: Davide Libenzi davidel@xmailserver.org
- Davide
Index: linux-2.6.20.ep2/fs/compat.c
===
--- linux-2.6.20.ep2.orig/fs/compat.c 2007-03
On Fri, 9 Mar 2007, Oleg Nesterov wrote:
Ugh. Still can't understand, probably I missed something or misread this
patch.
If we shift signalfd_notify() from
specific_send_sig_info/__group_send_sig_info
to send_signal(), we have the same list_empty() fastpath if no signalfds are
attached
On Thu, 8 Mar 2007, Davide Libenzi wrote:
+static ssize_t signalfd_read(struct file *file, char *buf, size_t count,
+ loff_t *ppos)
+{
+ struct signalfd_ctx *ctx = file-private_data;
+ struct sighand_struct *sighand = ctx-sighand;
+ ssize_t res = 0
On Thu, 8 Mar 2007, David M. Lloyd wrote:
On Wed, 2007-03-07 at 17:21 -0800, Davide Libenzi wrote:
int signalfd_dequeue(int fd, siginfo_t *info, long timeo);
The fd parameter must ba a signalfd file descriptor. The info parameter
is a pointer to the siginfo that will receive
*).
This allow code reuse, and will be used by epoll, signalfd and timerfd
(and whatever else there'll be).
Signed-off-by: Davide Libenzi davidel@xmailserver.org
- Davide
Index: linux-2.6.20.ep2/fs/anon_inodes.c
===
--- /dev/null
*/
__s32 svint;/* si_int */
__u64 svptr;/* si_ptr */
__u64 utime;/* si_utime */
__u64 stime;/* si_stime */
__u64 addr; /* si_addr */
};
Signed-off-by: Davide Libenzi davidel@xmailserver.org
- Davide
Index: linux-2.6.20.ep2/fs/signalfd.c
This patch wire the signalfd system call to the i386 architecture.
Signed-off-by: Davide Libenzi davidel@xmailserver.org
- Davide
Index: linux-2.6.20.ep2/arch/i386/kernel/syscall_table.S
===
--- linux-2.6.20.ep2.orig/arch/i386
This patch implement the necessary compat code for the signalfd system call.
Signed-off-by: Davide Libenzi davidel@xmailserver.org
- Davide
Index: linux-2.6.20.ep2/fs/compat.c
===
--- linux-2.6.20.ep2.orig/fs/compat.c 2007-03
This patch wire the signalfd system call to the x86_64 architecture.
Signed-off-by: Davide Libenzi davidel@xmailserver.org
- Davide
Index: linux-2.6.20.ep2/include/asm-x86_64/unistd.h
===
--- linux-2.6.20.ep2.orig/include/asm
This patch implement the necessary compat code for the timerfd system call.
Signed-off-by: Davide Libenzi davidel@xmailserver.org
- Davide
Index: linux-2.6.20.ep2/fs/compat.c
===
--- linux-2.6.20.ep2.orig/fs/compat.c 2007-03
This patch wire the timerfd system call to the x86_64 architecture.
Signed-off-by: Davide Libenzi davidel@xmailserver.org
- Davide
Index: linux-2.6.20.ep2/arch/x86_64/ia32/ia32entry.S
===
--- linux-2.6.20.ep2.orig/arch/x86_64
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
Signed-off-by: Davide Libenzi davidel@xmailserver.org
- Davide
Index: linux-2.6.20.ep2/fs
This patch wire the timerfd system call to the i386 architecture.
Signed-off-by: Davide Libenzi davidel@xmailserver.org
- Davide
Index: linux-2.6.20.ep2/arch/i386/kernel/syscall_table.S
===
--- linux-2.6.20.ep2.orig/arch/i386
On Sat, 10 Mar 2007, Jan Engelhardt wrote:
On Mar 9 2007 15:39, Davide Libenzi wrote:
This patch add an anonymous inode source, to be used for files that need
and inode only in order to create a file*. We do not care of having an
inode for each file, and we do not even care of having
On Fri, 9 Mar 2007, Davide Libenzi wrote:
This patch series implements the new signalfd() and signalfd_dequeue()
--
Of course, wrong description. The signalfd_dequeue() call is gone, and
signals are dequeued by read(2
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 timerfd code is, as you can probably read from
the code, a really thin wrapper around the existing
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 existing POSIX timer API?
The existing POSIX API is a standard and a very good one. Too bad it does
not deliver
On Fri, 9 Mar 2007, Davide Libenzi wrote:
+asmlinkage long compat_sys_timerfd(int ufd, int tmrtype,
+const struct timespec __user *utmr)
compat_timespec, that is.
- Davide
-
To unsubscribe from
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 POSIX timer API to deliver expiry events via a
fd.
It'll be out of standard as timerfd is, w/out code savings. Look
On Sat, 10 Mar 2007, Pavel Machek wrote:
Heh, this is what Al was saying ;)
I'm fine with that, but how about counter cycles (going back to zero)?
Just use u64?
Yeah, the second patch was using an u64.
I ended up using a class name (signalfd, timerfd, asyncfd) as dname
entry. An
On Sat, 10 Mar 2007, Oleg Nesterov wrote:
Davide Libenzi wrote:
+int signalfd_deliver(struct sighand_struct *sighand, int sig,
+struct siginfo *info)
+{
+ int nsig = 0;
+ struct list_head *pos;
+ struct signalfd_ctx *ctx;
+
+ list_for_each(pos, sighand
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 (subject to NTP correction), monotomic time
(not subject to NTP, will not ever go backwards or skip ticks), the
On Sat, 10 Mar 2007, Nicholas Miell wrote:
I never complained about one timer per fd (although, now that you
mention it, that would get a bit excessive if you have thousands of
outstanding timers).
Right, of course.
The real-time and monotonic selection can be added.
IOW, the timerfd
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_operations pointer).
That's already pretty smal, and the single inode (and maybe dentry) will
make it
*).
This allow code reuse, and will be used by epoll, signalfd and timerfd
(and whatever else there'll be).
Signed-off-by: Davide Libenzi davidel@xmailserver.org
- Davide
Index: linux-2.6.20.ep2/fs/anon_inodes.c
===
--- /dev/null
*/
__u64 svptr;/* si_ptr */
__u64 utime;/* si_utime */
__u64 stime;/* si_stime */
__u64 addr; /* si_addr */
};
Signed-off-by: Davide Libenzi davidel@xmailserver.org
- Davide
Index: linux-2.6.20.ep2/fs/signalfd.c
1 - 100 of 1521 matches
Mail list logo
