ntly, so it looks safe.
David, please pull it into your tree, or should it go via different path?
Acked-by: Evgeniy Polyakov
>> I don't see how it breaks UAPI. The point is that structures
>> coredump_proc_event and exit_proc_event are members of *union*
>> event_da
ector: add parent pid and tgid to coredump and
> exit events")
> Signed-off-by: Zhang Yu
> Signed-off-by: Li RongQing
Looks good to me, thank you!
Acked-by: Evgeniy Polyakov
> ---
> drivers/connector/cn_proc.c | 22 ++
> 1 file changed, 18 insertio
Hi everyone
Sorry for that late reply
01.03.2018, 21:58, "Stefan Strogin" :
> So I was thinking to add these two fields to union event_data:
> task->signal->group_exit_code
> task->signal->flags
> This won't increase size of struct proc_event (because of comm_proc_event)
> and shouldn't break bac
ned-off-by: Markus Elfring
Looks good to me, thanks Markus.
There is virtually zero useful information in this print if we are in the
situation, when kernel can not allocate
a few bytes to run connector queue.
Acked-by: Evgeniy Polyakov
kernel-janitors@ please queue this patch up
> --
but it is unused, and actually can not be at
all - there will be a deadlock, since sk_data_ready can be called with locked
socket and also in bh context.
I will setup this and report abck about bugs.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe net
offset, page_address(page) + offset, len);
> +#else
> + p = page;
> + get_page(p);
> +#endif
Some pages have zero reference counter here.
Is commented NET_COPY_SPLICE part from old implementation?
It will be always slower than existing approach due to allocation
overhead.
--
On Tue, Jun 05, 2007 at 06:31:31PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> [ 263.936418] RIP [] skb_splice_bits+0xac/0x1c9
> [ 263.942516] RSP
>
> This a vm_bug_on in get_page().
>
> > +static inline int spd_fill_page(struct splice_pipe_desc *spd, s
ia priviate pointers) and do not perform any kind of reference counting
on them? I will play with this a bit later today.
> --
> Jens Axboe
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
- slab does not allow anyone to
manipulate page's members. That should be broken/changed to allow splice
to put its hands into network using the fastest way.
I will think about it.
> --
> Jens Axboe
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "uns
ed by stack using the same transmit lock.
Where is a gain?
Btw, this one forces a smile:
if (unlikely(ret != NETDEV_TX_OK))
return NETDEV_TX_OK;
P.S. I do not have e1000 hardware to test, the only testing machine has
r8169 driver.
--
Evgeniy Polyakov
-
To
On Thu, Jun 07, 2007 at 06:23:16PM -0400, jamal ([EMAIL PROTECTED]) wrote:
> On Thu, 2007-07-06 at 20:13 +0400, Evgeniy Polyakov wrote:
>
> > Actually I wonder where the devil lives, but I do not see how that
> > patchset can improve sending situation.
> > Let m
mption, we can extend the size of the pipe and keep
> going.
I have a code, which roughly works (but I will test it some more), which
just introduces reference counters for slab pages, so that the would not
be actually freed via page reclaim, but only after reference counters
are dropped. That forced
On Fri, Jun 08, 2007 at 07:31:07AM -0400, jamal ([EMAIL PROTECTED]) wrote:
> On Fri, 2007-08-06 at 12:38 +0400, Evgeniy Polyakov wrote:
> > On Thu, Jun 07, 2007 at 06:23:16PM -0400, jamal ([EMAIL PROTECTED]) wrote:
>
> > > I believe both are called with no lock. The idea
struct sk_buff *skb,
unsigned int *offset,
if (plen > *total_len)
plen = *total_len;
-
+#if 0
+ printk("%s: skb_data: %p, ptr: %p, len: %u, headlen: %u, page:
%p, plen: %u, poff: %u.\n",
+ __func__, skb->data, p, len, headlen,
virt_to_page(p), plen, poff);
+#endif
if (spd_fill_page(spd, virt_to_page(p), plen, poff))
break;
> --
> Jens Axboe
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
o work on this idea.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jun 08, 2007 at 06:57:25PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> I will try some things for the nearest 30-60 minutes, and then will move to
> canoe trip until thuesday, so will not be able to work on this idea.
Ok, replacing in fs/splice.c every page_cache_release(
s?
/proc/$pid/stat, for pktgen it is likely not that interesting, but for
usual userspace applcation it is quite interesting parameter.
At least that is what 'top' shows.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the
On Sat, Jun 09, 2007 at 08:36:09AM +0200, Jens Axboe ([EMAIL PROTECTED]) wrote:
> On Fri, Jun 08 2007, Evgeniy Polyakov wrote:
> > On Fri, Jun 08, 2007 at 06:57:25PM +0400, Evgeniy Polyakov ([EMAIL
> > PROTECTED]) wrote:
> > > I will try some things for the nearest 30-6
From another side, ->bi_destructor() can do
whatever it wants with bio without any check for its reference counter.
According to sk_eat_skb() - it is an optimisation to remove atomic
check.
> --
> Jens Axboe
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jun 12, 2007 at 02:40:05PM +0200, Jens Axboe ([EMAIL PROTECTED]) wrote:
> On Tue, Jun 12 2007, Evgeniy Polyakov wrote:
> > > > > > and putting cloned skb into private field instead of
> > > > > > original on in spd_fill_page() ends up without kerne
sys_splice+0x1a8/0x232
[ 52.158733] [] system_call+0x7e/0x83
[ 52.164005]
[ 52.165544]
[ 52.165545] Code: 0f 0b eb fe 44 39 65 d4 8b 4d d4 41 0f 47 cc 90 ff
42 08 48
[ 52.175364] RIP [] __skb_splice_bits+0xcd/0x201
[ 52.181636] RSP
--
Evgeniy Polyakov
-
To unsubscribe
On Tue, Jun 12, 2007 at 08:17:32PM +0200, Jens Axboe ([EMAIL PROTECTED]) wrote:
> On Tue, Jun 12 2007, Evgeniy Polyakov wrote:
> > On Mon, Jun 11, 2007 at 01:59:26PM +0200, Jens Axboe ([EMAIL PROTECTED])
> > wrote:
> > > Patches are against the #splice branch of the bl
On Wed, Jun 13, 2007 at 12:01:04PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> I will rebase my tree, likely something was not merged correctly.
Ok, I've just rebased a tree from recent git and pulled from brick -
things seems to be settled. I've ran several tests w
On Thu, Jun 14, 2007 at 01:59:02PM +0200, Jens Axboe ([EMAIL PROTECTED]) wrote:
> On Thu, Jun 14 2007, Evgeniy Polyakov wrote:
> > On Wed, Jun 13, 2007 at 12:01:04PM +0400, Evgeniy Polyakov ([EMAIL
> > PROTECTED]) wrote:
> > > I will rebase my tree, likely something
received correctly.
> >
> > Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
> >
> > diff --git a/fs/splice.c b/fs/splice.c
> > index bc481f1..365bfd9 100644
> > --- a/fs/splice.c
> > +++ b/fs/splice.c
> > @@ -211,8 +211,6 @@ ssize_t splice_to_
}
>
> - while (page_nr < spd->nr_pages)
> + while (page_nr < spd_pages)
> spd->spd_release(spd, page_nr++);
>
> return ret;
>
> --
> Jens Axboe
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "uns
On Tue, Jun 19, 2007 at 05:21:48PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> Simple test included test -> desktop and vice versa traffic with 128 and
> 4096 block size in netperf-2.4.3 setup.
I.e. it is not pktgen, but usual userspace application, which should not
use
On Tue, Jun 19, 2007 at 05:33:33PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> On Tue, Jun 19, 2007 at 05:21:48PM +0400, Evgeniy Polyakov ([EMAIL
> PROTECTED]) wrote:
> > Simple test included test -> desktop and vice versa traffic with 128 and
> > 4096 block size i
.22-rc5-mainline:
128: 558.16 (Desired confidence was not achieved within the specified
iterations.)
4096: 814.01
2.6.22-rc5-batch:
128: 569.14 (Desired confidence was not achieved within the specified
iterations.)
4096: 822.72
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the lin
On Tue, Jun 19, 2007 at 06:00:39PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> On Tue, Jun 19, 2007 at 05:33:33PM +0400, Evgeniy Polyakov ([EMAIL
> PROTECTED]) wrote:
> > On Tue, Jun 19, 2007 at 05:21:48PM +0400, Evgeniy Polyakov ([EMAIL
> > PROTECTED]) wrote:
On Tue, Jun 19, 2007 at 12:28:49PM -0400, jamal ([EMAIL PROTECTED]) wrote:
> On Tue, 2007-19-06 at 18:00 +0400, Evgeniy Polyakov wrote:
>
> > pktgen reults are quite poor:
> > batch (changed from default script: count reduced, clone increased to 10k)
> > 241319pps 115Mb/se
"
$
> I will try to turn on those in a few days and see if notice a
> difference.
It is turned off.
> Again, thanks Evgeniy.
No problem.
> cheers,
> jamal
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body o
t; Result: OK: T4143884(U4143864+I20+A4007752+T127073) usec, P100
> > TE8511TS1(B60,-1frags)
>
> So on average you have been sending about 120 packets per batch - which
> should give you decent numbers. Lets see how Robert responds and if you
> have time, turn off the k
e
tsc acpi_pm jiffies
Config is exactly the same, so the same should be all parameters.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
ec
So, that is definitely a sign, that batching has some issues with skb
reusage.
> cheers,
> jamal
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vge
99,5 -- -m 128 -s 128K
-S 128K
so without nodelay.
With nodelay I've gotten:
batch-128: 128.91 mbit/sec
mainline-128: 140.57 mbit/sec
which is about 5 times less than withouth nodelay (~760 mbit/s)
Although nodelay results look more realistic.
> rick jones
--
Evgeniy Polyako
no per-addr limits.
If there is some kind of binds, then yes, only 64k ports per address.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
so on.
> Thanks,
> Brice
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
a thread about problems limiting 2^32 group space, while no
user has even more than 10...
> johannes
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
> + lro->skb_sg_cnt = 1;
> + lro->ip_tot_len = ntohs(iph->tot_len);
> +
> + if (tcph->doff == 8) {
> + ptr = (u32 *)(tcph+1);
> + lro->tcp_saw_tstamp = 1;
> + lro->tcp_rcv_tsval = *(ptr+1);
> + lro->tcp_rcv_tsecr = *(ptr+2);
> + }
> +
> + if (cqe->status & EHEA_CQE_VLAN_TAG_XTRACT) {
> + lro->vlan_packet = 1;
> + lro->vlan_tag = cqe->vlan_tag;
> + }
> +
> + lro->active = 1;
> +}
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
s performance, that is why skb has only
one control structure and data area, which incorporates additional
control information, thus there is no need for multiple destructors.
> Regards,
> Jarek P.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe
lperfunctions.
> What do you think about putting them into /net/ipv4/inet_lro.c and
> /include/linux/inet_lro.h ?
The more I think, the more it looks as appropriate to be used by all hardware
drivers with proper API. As far as I recall this is third implementation
in the linux drivers :)
--
dev->features |= NETIF_F_LLTX;
> + dev->init = veth_dev_init;
> + dev->destructor = veth_dev_free;
> + netif_carrier_off(dev);
> +}
Don't you want to include NETIF_F_SG, NETIF_F_NO_CSUM, NETIF_F_FRAGLIST,
NETIF_F_HIGHDMA and probably TSO fancy flags also to reduce
et_lro_desc *lro_desc;
> +struct iphdr *iph;
> +struct tcphdr *tcph;
> +
> + if (!lro_mgr->get_ip_tcp_hdr
> + || lro_mgr->get_ip_tcp_hdr(skb, &iph, &tcph, priv))
> + goto out;
> +
> + lro_desc = lro_get_desc(lro_m
t is a derivative of the netlink support in
> scsi_transport_iscsi.c.
I'm not sure about all net guys, but the first question rised after
reading this - why do you want special netlink family and do not want to
use interfaces created on top of - like connector and genetlink?
> -and
.
It really looks like the last tree we tested, so if you think additional
one will not hurt, feel free to ping, so I will completely rebase
testing tree.
> --
> Jens Axboe
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the b
e day when everyone started to depend on networking :)
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
n Kconfig.
Although this patch can help too.
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
diff --git a/net/ieee80211/Kconfig b/net/ieee80211/Kconfig
index 1438ade..a23414f 100644
--- a/net/ieee80211/Kconfig
+++ b/net/ieee80211/Kconfig
@@ -1,5 +1,6 @@
config IEEE80211
trista
On Mon, Jul 16, 2007 at 11:36:19AM +0200, Toralf Förster ([EMAIL PROTECTED])
wrote:
> Am Montag, 16. Juli 2007 10:32 schrieb Evgeniy Polyakov:
> > This is a result of 'select' usage in Kconfig.
> > Although this patch can help too.
> >
>
> Hi,
> unfortunat
building IrDA as a module. My apologies
> for that.
What about having all of them __devinit/__devexit?
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
x27;dev' prefix I suggested.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
gt; cycles to do the same. :)
That would be great!
Please don't think that I wash people's mind with weekly "get it, get it"
zombying stuff, I completely understand that there are things with much
higher priority that netchannels, so it can wait (for a while :).
Thank you.
ULT.
> --
> Mit freundlichen Grüßen / Best Regards
>
> Christian Borntraeger
> Linux Software Engineer zSeries Linux & Virtualization
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jul 18, 2006 at 02:36:57PM +0200, Christian Borntraeger ([EMAIL
PROTECTED]) wrote:
> On Tuesday 18 July 2006 13:51, Evgeniy Polyakov wrote:
> > > I think this should be -EFAULT instead of -ERESTARTSYS, right?
> >
> > I have no strong feeling on what must be retur
fter looking into Van's presentation (and his words about
_userspace_ protocol processing) I think they used own stack too.
So I reinvented the wheel and created my own too.
> J?rn
>
> --
> When people work hard for you for a pat on the back, you've got
> to give them that pat.
&g
t netchannels.
I showed there, that using existing stack it is imposible to get big
performance win (although I tested my patches with 1gb only), since
there are some nitpicks on sending side (now I think it is congestion
control, but I'm not 100% sure).
The only thing my TCP stack impleme
On Wed, Jul 19, 2006 at 09:38:41AM +0400, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> There is no socket spinlock anymore.
> Above lock is skb_queue lock which is held inside
> skb_dequeue/skb_queue_tail calls.
>
> > > one mutex for netchannel's bucket
> >
&g
t it is very hard), then it is not
interesting.
I definitely do not say, that it must be removed/replaced/anything - it
works perfectly ok, but it is possible to have better performance by
changing architecture, and it was done.
>Alexey
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
tup, so
they can not be compared with Van's.
But even with 1gb I was not satisfied with them, so I started different
implementation, which I described in my e-mail to Alexey.
1. speed/cpu measurements of one of the netchannels implementation which
used socket code.
http://thread.gmane.org/gmane.
ot enough for me, so I implemented different stack, which does not
have anything related to the two step processing, and it can be one of the
reasons
for faster processing. It can have bugs, but the whole idea was proven
to be absolutely correct (when using either socket code, or atcp).
That was my opinion on the topic. It looks like neither you, nor me will
not change our point of view about that right now :)
But anyway it is a good discussion, let's see what others think about
it.
> Alexey
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
s cpu utilization. I think these two things are no
> coincidence. :-)
TSO/GSO is a good idea definitely, but it is completely unrelated to
other problems. If it will be implemented with netchannels we will have
even better perfomance.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
logic...)
I do not think it is possible with additional logic like what is
implemented in softirqs, i.e. per cpu queues of data, which in turn will
be converted into skbs one-by-one.
> Thanks,
> Ben
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe
On Fri, Jul 21, 2006 at 11:19:00AM +0400, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> On Thu, Jul 20, 2006 at 02:21:57PM -0700, Ben Greear ([EMAIL PROTECTED])
> wrote:
> > Out of curiosity, is it possible to have the single producer logic
> > if you have two+ ethernet i
blogspot.com
> WAND Network Research Group
> Department of Computer Science
> University of Waikato
> New Zealand
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
dons_ to the exisintg design do not and can not _change_ it's nature
(I do not say, that it is a problem, but nature of the existing network
stack design), and that addons (like TSO, GSO and any other) helps to
any stack, but stack itself is not a problem.
I do not want to say, that existing tc
On Fri, Jul 21, 2006 at 02:19:55AM -0700, David Miller ([EMAIL PROTECTED])
wrote:
> From: Evgeniy Polyakov <[EMAIL PROTECTED]>
> Date: Fri, 21 Jul 2006 13:06:11 +0400
>
> > Receiving side, nor matter if it is socket or netchannel, will drop
> > packets (socket due to
so on.
Blocking on write will not trigger memory limits overcommit from the
first packet, as long as it will not trigger timeout retransmit if no
acks are sent. If there will be a lot of them, then troubles start.
We saw already, that speed decreased to the write speed in both
implementations without c
which then will be processed one-by-one by _exactly_ single user.
That user can get skb in round-robin manner and put them into socket
queue and call protocol receiving function.
> --
> Ben Greear <[EMAIL PROTECTED]>
> Candela Technologies Inc http://www.candelatech.com
--
rget a
> different cpu thread.
And if that CPU is very busy?
Linux should somehow tell NIC that some CPUs are valid and some are not
right now, but not in a second, so scheduler must be tightly bound with
network internals.
Just my 2 coins.
--
Evgeniy Polyakov
-
To unsubscribe from th
On Mon, Jul 24, 2006 at 11:17:08PM -0700, David Miller ([EMAIL PROTECTED])
wrote:
> From: Evgeniy Polyakov <[EMAIL PROTECTED]>
> Date: Sun, 9 Jul 2006 17:24:46 +0400
>
> > This patch includes core kevent files:
> > - userspace controlling
> > - kernelspace
unrelated to either my or others work note :) -
I think it is a nanooptimisation - we get a bit of performance here,
and lose those bit in other place.
When bag is filled, there is no much sence of rearranging some stuff
inside to be able to place another one - it is better to buy new bag.
--
On Tue, Jul 25, 2006 at 12:33:44AM -0700, David Miller ([EMAIL PROTECTED])
wrote:
> From: Evgeniy Polyakov <[EMAIL PROTECTED]>
> Date: Tue, 25 Jul 2006 10:59:21 +0400
>
> > As a side completely unrelated to either my or others work note :) -
> > I think it is a nano
+0x47/0x19a
It is not a bug, but remind to update nat helper function.
> --
> Tomasz Torcz"Funeral in the morning, IDE hacking
> [EMAIL PROTECTED]in the afternoon and evening." - Alan Cox
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the
section=projects&item=kevent
2. network aio homepage.
http://tservice.net.ru/~s0mbre/old/?section=projects&item=naio
3. LWN.net published a very good article about kevent.
http://lwn.net/Articles/172844/
Thank you.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> What next?
It is not a bug, but remind to update NAT helper function.
It has nothing with device drivers and is only printed once.
> Eike
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTE
management, since iteractive timers are very inconveniently to use,
and they are limited.
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
diff --git a/kernel/kevent/kevent_poll.c b/kernel/kevent/kevent_poll.c
new file mode 100644
index 000..4950e7c
--- /dev/null
+++ b/kernel/kevent/kevent_
sendfile() callback.
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
diff --git a/fs/bio.c b/fs/bio.c
index 6a0b9ad..a3ee530 100644
--- a/fs/bio.c
+++ b/fs/bio.c
@@ -119,7 +119,7 @@ void bio_free(struct bio *bio, struct bi
/*
* default destructor for a bio allocated with bi
published a very good article about kevent.
http://lwn.net/Articles/172844/
Thank you.
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
to do checksumming, I'm a bit lazy, it is in TODO)
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
diff --git a/kernel/kevent/kevent_socket.c b/kernel/kevent/kevent_socket.c
new file mode 100644
index 000..c230aaa
--- /dev/null
+++ b/kernel/kevent/kevent_socket
works_with_blocks_and_kevents()
instead of
fs/some_function_which_works_with_block_and_kevents()
kevent/call_that_function_like_all_readpage_callbacks_do().
So it is not a technical problem, but political one.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "un
On Wed, Jul 26, 2006 at 11:04:31AM +0100, Christoph Hellwig ([EMAIL PROTECTED])
wrote:
> On Wed, Jul 26, 2006 at 01:18:15PM +0400, Evgeniy Polyakov wrote:
> >
> > This patch includes asynchronous propagation of file's data into VFS
> > cache and aio_sendfile() i
On Wed, Jul 26, 2006 at 11:13:56AM +0100, Christoph Hellwig ([EMAIL PROTECTED])
wrote:
> On Wed, Jul 26, 2006 at 02:08:49PM +0400, Evgeniy Polyakov wrote:
> > On Wed, Jul 26, 2006 at 11:00:13AM +0100, Christoph Hellwig ([EMAIL
> > PROTECTED]) wrote:
> > > > stru
if (file->f_fop != &kevent_user_fops)
> return -EINVAL;
Thanks, I will implement both.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jul 26, 2006 at 01:18:15PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> +struct kevent *kevent_alloc(gfp_t mask)
> +{
> + struct kevent *k;
> +
> + if (kevent_cache)
> + k = kmem_cache_alloc(kevent_cache, mask);
> + else
> +
On Wed, Jul 26, 2006 at 11:10:55PM -0700, David Miller ([EMAIL PROTECTED])
wrote:
> From: Evgeniy Polyakov <[EMAIL PROTECTED]>
> Date: Wed, 26 Jul 2006 10:28:17 +0400
>
> > I have not created additional DMA memory allocation methods, like
> > Ulrich described in
On Thu, Jul 27, 2006 at 01:02:55AM -0700, David Miller ([EMAIL PROTECTED])
wrote:
> From: Evgeniy Polyakov <[EMAIL PROTECTED]>
> Date: Thu, 27 Jul 2006 11:49:02 +0400
>
> > I.e. map skb's data to userspace? Not a good idea especially with it's
> > tricky li
On Thu, Jul 27, 2006 at 02:31:56AM -0700, David Miller ([EMAIL PROTECTED])
wrote:
> From: Evgeniy Polyakov <[EMAIL PROTECTED]>
> Date: Thu, 27 Jul 2006 12:58:13 +0400
>
> > Btw, according to DMA allocations - there are some problems here too.
> > Some pieces of the wo
s between hard and soft irqs, so acks will
be delayed and so on... But stack works without problems even if some
kernel thread takes 100% cpu (with preemption), and there are very big
delays for ack generations, but userspace is not possible to get that
data. With netchannels it is essential
system scales well and does not eat resources, but it has a
problem, that not very much info can be delivered to user when event is
ready (for example no filenames, only inode number can be transferred).
> So how does this sound? It wouldn't take me long to build this off of
> the current kevent patches. We could see how it looks..
I especially like idea about world happinness in a week or so :)
> - z
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
ect from non-preemptible kernel? Hard lockup, no acks,
no soft irqs. So this case still does not differ from process' context
processing.
And after several minutes I pressed hardware reset button...
> Alexey
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "
that some events already fired and
such requests will return immediately, or for example how timer events
will be managed?
> > I especially like idea about world happinness in a week or so :)
>
> A few weeks! :)
No matter after couple of millions of years of human evolution :)
&g
On Thu, Jul 27, 2006 at 10:34:00PM -0700, David Miller ([EMAIL PROTECTED])
wrote:
> From: Evgeniy Polyakov <[EMAIL PROTECTED]>
> Date: Fri, 28 Jul 2006 09:17:25 +0400
>
> > What would you expect from non-preemptible kernel? Hard lockup, no acks,
> > no soft irqs.
>
ork on the next. By keeping each step small and managable,
> the properties of the system are much easier to predict. Yes, batching
> can be helpful performance-wise, but it is somewhat opposite to the design
> criteria that need to be considered. The right way to cope with that may
> be to have two different modes of operation that trade off one way or the
> other on the batching question.
It is user who should decide either he wants one, all or at least one
eventt. kevent supports all types of requests, it's behaviour depends on
parameters.
> -ben
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
.
For example connector (idealogical parent of gennetlink) does not have
such attributes, but has similar to your structures approach, so it is
only the way you like to represent your data.
> --
> paul moore
> linux security @ hp
--
Evgeniy Polyakov
-
To unsubscribe from this
dataflow?
According to syscall speed on Linux, last time I checked empty syscall
took about 100ns on AMD Athlon 3500+.
> - z
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
ttp://tservice.net.ru/~s0mbre/old/?section=projects&item=kevent
> - z
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
ready, and not to check and then get them?
Could you please explain more on this issue?
> --
> ??? Ulrich Drepper ??? Red Hat, Inc. ??? 444 Castro St ??? Mountain View, CA
> ???
>
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev&q
t see
immediate benefits from that.
> --
> Nicholas Miell <[EMAIL PROTECTED]>
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Jul 29, 2006 at 09:18:47AM -0700, Ulrich Drepper ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov wrote:
> > Btw, why do we want mapped ring of ready events?
> > If user requestd some event, he definitely wants to get them back when
> > they are ready, and not to ch
On Mon, Jul 31, 2006 at 08:35:55PM +1000, Herbert Xu ([EMAIL PROTECTED]) wrote:
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >
> >> - if there is space, report it in the ring buffer. Yes, the buffer
> >> can be optional, then all events are reported by the sy
1 - 100 of 1256 matches
Mail list logo
