deadlock.
If you do not like such calculation, solution is trivial:
we can sleep _after_ -make_request_fn() in
generic_make_request() until number of in-flight bios is reduced by
bio_endio().
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
data structures in the network path.
Above example just has 1gb of ram, which should be enough for skbs, if
it is not, decrease limit to 500 mb and so on, until weighted load of
the system allows to always have a forward progress.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send
p of distributed storage (which is a urprise to me, that holy zfs
suppors that)?
> Thanks!
>
> --
> Al
>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http:/
(which is a urprise to me, that holy zfs
suppors that)?
Thanks!
--
Al
-
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
--
Evgeniy Polyakov
alid name? I can't imagine how to call it.
:) what about name, which really shows what option does?
--
Evgeniy Polyakov
-
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://vg
sting
applications.
--
Evgeniy Polyakov
-
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/
it.
:) what about name, which really shows what option does?
--
Evgeniy Polyakov
-
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
.
--
Evgeniy Polyakov
-
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/
On Thu, Aug 09, 2007 at 08:13:54PM +0200, Unai Uribarri ([EMAIL PROTECTED])
wrote:
> On jue, 2007-08-09 at 18:33 +0400, Evgeniy Polyakov wrote:
> > On Thu, Aug 09, 2007 at 04:21:54PM +0200, Unai Uribarri ([EMAIL PROTECTED])
> > wrote:
> > > The attached patch removes
w tcpdump with mmap libpcap will work with it?
--
Evgeniy Polyakov
-
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/
with mmap libpcap will work with it?
--
Evgeniy Polyakov
-
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/
On Thu, Aug 09, 2007 at 08:13:54PM +0200, Unai Uribarri ([EMAIL PROTECTED])
wrote:
On jue, 2007-08-09 at 18:33 +0400, Evgeniy Polyakov wrote:
On Thu, Aug 09, 2007 at 04:21:54PM +0200, Unai Uribarri ([EMAIL PROTECTED])
wrote:
The attached patch removes the automatic timestamp activation
On Wed, Aug 08, 2007 at 02:17:09PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> This throttling mechanism allows to limit maximum amount of queued bios
> per physical device. By default it is turned off and old block layer
> behaviour with unlimited number of bios is used. Wh
are not atomic, since we do not care about
precise number of bios, but a fact, that we are close or close enough to
the limit.
Tested on distributed storage device - with limit of 2 bios it works
slow :)
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
diff --git a/block/ll_rw_blk.c b
nce
of bio->bi_bdev = something_new with blk_set_bdev(bio, somthing_new),
where queue limits will be appropriately charged. So far I'm testing
second case, but I only changed DST for testing, can change all other
users if needed though.
--
Evgeniy Polyakov
-
To unsubscribe from thi
of bio-bi_bdev = something_new with blk_set_bdev(bio, somthing_new),
where queue limits will be appropriately charged. So far I'm testing
second case, but I only changed DST for testing, can change all other
users if needed though.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send
are not atomic, since we do not care about
precise number of bios, but a fact, that we are close or close enough to
the limit.
Tested on distributed storage device - with limit of 2 bios it works
slow :)
Signed-off-by: Evgeniy Polyakov [EMAIL PROTECTED]
diff --git a/block/ll_rw_blk.c b/block
On Wed, Aug 08, 2007 at 02:17:09PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
This throttling mechanism allows to limit maximum amount of queued bios
per physical device. By default it is turned off and old block layer
behaviour with unlimited number of bios is used. When turned
The intention is to _just_ reserve the addr/port.
Above RDMA ->bind() ends up with tcp_v4_get_port(), which will only add
socket into bhash, but it is only accessible for new sockets created for
listening connections or expilicit bind, network traffic checks only
listening and establised h
ken offloading, this one will result in
the case, when usual network dataflow can enter private rdma land, i.e.
after bind succeeded this socket is accessible via any other network
device. Is it inteded?
And this is quite noticeble overhead per rdma connection, btw.
--
Evgeniy Polyako
network dataflow can enter private rdma land, i.e.
after bind succeeded this socket is accessible via any other network
device. Is it inteded?
And this is quite noticeble overhead per rdma connection, btw.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line unsubscribe
traffic checks only
listening and establised hashes, which are not affected by above change,
so it was false alarm from my side. It does allow to 'grab' a port and
forbid its possible reuse.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Sun, Aug 05, 2007 at 02:35:04PM -0700, Daniel Phillips ([EMAIL PROTECTED])
wrote:
> On Sunday 05 August 2007 08:01, Evgeniy Polyakov wrote:
> > On Sun, Aug 05, 2007 at 01:06:58AM -0700, Daniel Phillips wrote:
> > > > DST original code worked as device mapper pl
On Sun, Aug 05, 2007 at 02:23:45PM -0700, Daniel Phillips ([EMAIL PROTECTED])
wrote:
> On Sunday 05 August 2007 08:08, Evgeniy Polyakov wrote:
> > If we are sleeping in memory pool, then we already do not have memory
> > to complete previous requests, so we are in trouble.
>
On Sun, Aug 05, 2007 at 02:23:45PM -0700, Daniel Phillips ([EMAIL PROTECTED])
wrote:
On Sunday 05 August 2007 08:08, Evgeniy Polyakov wrote:
If we are sleeping in memory pool, then we already do not have memory
to complete previous requests, so we are in trouble.
Not at all. Any requests
On Sun, Aug 05, 2007 at 02:35:04PM -0700, Daniel Phillips ([EMAIL PROTECTED])
wrote:
On Sunday 05 August 2007 08:01, Evgeniy Polyakov wrote:
On Sun, Aug 05, 2007 at 01:06:58AM -0700, Daniel Phillips wrote:
DST original code worked as device mapper plugin too, but its two
additional
c_make_request() when new
bio is going to be submitted and it is about to exceed the limit?
By default things will be like they are now, except additional
non-atomic increment and branch in generic_make_request() and decrement
and wake in bio_end_io()?
I can cook up such a patch if idea worth efforts.
misread. A show stopper in terms of efficiency, or in
> terms of deadlock?
At least as in terms of efficiency. Device mapper lives in happy world
where memory does not end and allocations are fast.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsub
of efficiency, or in
terms of deadlock?
At least as in terms of efficiency. Device mapper lives in happy world
where memory does not end and allocations are fast.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
they are now, except additional
non-atomic increment and branch in generic_make_request() and decrement
and wake in bio_end_io()?
I can cook up such a patch if idea worth efforts.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On Fri, Aug 03, 2007 at 09:04:51AM +0400, Manu Abraham ([EMAIL PROTECTED])
wrote:
> On 7/31/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> > TODO list currently includes following main items:
> > * redundancy algorithm (drop me a request of yo
Hi Daniel.
> On Tuesday 31 July 2007 10:13, Evgeniy Polyakov wrote:
> > * storage can be formed on top of remote nodes and be exported
> > simultaneously (iSCSI is peer-to-peer only, NBD requires device
> > mapper and is synchronous)
>
> In fact, NBD ha
ways called in process context, we can wait in it
for memory in mempool. Although that means we already in trouble.
I agree, any kind of high-boundary leveling must be implemented in
device itself, since block layer does not know what device is at the end
and what it will need to process given block r
of high-boundary leveling must be implemented in
device itself, since block layer does not know what device is at the end
and what it will need to process given block request.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
Hi Daniel.
On Tuesday 31 July 2007 10:13, Evgeniy Polyakov wrote:
* storage can be formed on top of remote nodes and be exported
simultaneously (iSCSI is peer-to-peer only, NBD requires device
mapper and is synchronous)
In fact, NBD has nothing to do with device mapper. I
On Fri, Aug 03, 2007 at 09:04:51AM +0400, Manu Abraham ([EMAIL PROTECTED])
wrote:
On 7/31/07, Evgeniy Polyakov [EMAIL PROTECTED] wrote:
TODO list currently includes following main items:
* redundancy algorithm (drop me a request of your own, but it is highly
unlikley
On Fri, Aug 03, 2007 at 02:27:52PM +0200, Peter Zijlstra ([EMAIL PROTECTED])
wrote:
> On Fri, 2007-08-03 at 14:57 +0400, Evgeniy Polyakov wrote:
>
> > For receiving situation is worse, since system does not know in advance
> > to which socket given packet will belong to, so it
On Fri, Aug 03, 2007 at 02:26:29PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> > Memory deadlock is a concern of course. From a cursory glance through,
> > it looks like this code is pretty vm-friendly and you have thought
> > quite a lot about it, however I respectf
Hi.
On Fri, Aug 03, 2007 at 09:04:51AM +0400, Manu Abraham ([EMAIL PROTECTED])
wrote:
> On 7/31/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> > TODO list currently includes following main items:
> > * redundancy algorithm (drop me a request of yo
DST
> through its paces.
In that blog entry I misspelled Zen with Xen - that's an error,
according to prognosis - time will judge :)
> regards,
> Mike
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to [EMAIL PROTECTE
On Thu, Aug 02, 2007 at 02:08:24PM -0700, Daniel Phillips ([EMAIL PROTECTED])
wrote:
> On Tuesday 31 July 2007 10:13, Evgeniy Polyakov wrote:
> > Hi.
> >
> > I'm pleased to announce first release of the distributed storage
> > subsystem, which allows to form a storage
On Fri, Aug 03, 2007 at 02:26:29PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
Memory deadlock is a concern of course. From a cursory glance through,
it looks like this code is pretty vm-friendly and you have thought
quite a lot about it, however I respectfully invite peterz
On Fri, Aug 03, 2007 at 02:27:52PM +0200, Peter Zijlstra ([EMAIL PROTECTED])
wrote:
On Fri, 2007-08-03 at 14:57 +0400, Evgeniy Polyakov wrote:
For receiving situation is worse, since system does not know in advance
to which socket given packet will belong to, so it must allocate from
On Thu, Aug 02, 2007 at 02:08:24PM -0700, Daniel Phillips ([EMAIL PROTECTED])
wrote:
On Tuesday 31 July 2007 10:13, Evgeniy Polyakov wrote:
Hi.
I'm pleased to announce first release of the distributed storage
subsystem, which allows to form a storage on top of remote and local
nodes
Hi.
On Fri, Aug 03, 2007 at 09:04:51AM +0400, Manu Abraham ([EMAIL PROTECTED])
wrote:
On 7/31/07, Evgeniy Polyakov [EMAIL PROTECTED] wrote:
TODO list currently includes following main items:
* redundancy algorithm (drop me a request of your own, but it is highly
unlikley
-
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
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
l() callbacks.
> Cheers,
> Kyle Moffett
--
Evgeniy Polyakov
-
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/
Moffett
--
Evgeniy Polyakov
-
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/
void *mac_hdr,
> + int hlen)
> +{
> + struct sk_buff *skb;
> +struct skb_frag_struct *skb_frags;
> + int data_len = len;
The same.
> + skb = netdev_alloc_skb(lro_mgr->dev, hlen);
> + if (!skb)
> + retu
);
+ if (!skb)
+ return NULL;
+
+skb-len = len;
+ skb-data_len = len - hlen;
Here too.
There is number of such places, ommitted others.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
On Sat, Jul 21, 2007 at 05:03:00PM +0200, Jesper Juhl ([EMAIL PROTECTED]) wrote:
> Hi,
Hi Jesper.
> This patch cleans up duplicate includes in
> drivers/w1/
Thanks for the patch.
> Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
Acked-by: Evgeniy Polyakov
On Sat, Jul 21, 2007 at 05:03:00PM +0200, Jesper Juhl ([EMAIL PROTECTED]) wrote:
Hi,
Hi Jesper.
This patch cleans up duplicate includes in
drivers/w1/
Thanks for the patch.
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
Acked-by: Evgeniy Polyakov [EMAIL PROTECTED
skb leak, no crashes (quite a few debug options are turned on
in config) and files are correct on both peers, so it works good.
> --
> Jens Axboe
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EM
debug options are turned on
in config) and files are correct on both peers, so it works good.
--
Jens Axboe
--
Evgeniy Polyakov
-
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
I have no problem with this patch. Should I forward it to Andrew or you
will pick this up?
Acked-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTE
when everyone started to depend on networking :)
--
Evgeniy Polyakov
-
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/
events.
On my machine device mapper (lvm, raid) does not work without sockets,
(maybe not dm, but hotplug, which creates nodes, or configuration)
so it already depends on it. Hotplug depends on networking.
You missed the day when everyone started to depend on networking :)
--
Evgeniy Polyakov
with this patch. Should I forward it to Andrew or you
will pick this up?
Acked-by: Evgeniy Polyakov [EMAIL PROTECTED]
--
Evgeniy Polyakov
-
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
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 linux-kernel" in
the body of a message t
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?
> -andm
esc;
> +struct iphdr *iph;
> +struct tcphdr *tcph;
> +
> + if (!lro_mgr->get_ip_tcp_hdr
> + || lro_mgr->get_ip_tcp_hdr(skb, , , priv))
> + goto out;
> +
> + lro_desc = lro_get_desc(lro_mgr, lro_mgr->lro_arr, ip
?
--
Evgeniy Polyakov
-
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/
special netlink family and do not want to
use interfaces created on top of - like connector and genetlink?
-andmike
--
Evgeniy Polyakov
-
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
to ping, so I will completely rebase
testing tree.
--
Jens Axboe
--
Evgeniy Polyakov
-
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
unctions.
> 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 :)
--
/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 :)
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line
re unique identifiers which
> >
> >
>
> Evgeniy, could you please review this?
>
> The need to add these enumerations for unrelated subsystems to connector.h
> may get a bit ugly as time passes, but I guess it's OK for now.
Hi.
I have no problem with the patc
to split
patch to two - add id and increase the size, but it is too minor nit.
Ack.
--
Evgeniy Polyakov
-
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
On Fri, Jun 15, 2007 at 01:14:04PM +0200, Jörn Engel ([EMAIL PROTECTED]) wrote:
> On Fri, 15 June 2007 13:03:57 +0400, Evgeniy Polyakov wrote:
> > On Sun, Jun 03, 2007 at 08:46:04PM +0200, Jörn Engel ([EMAIL PROTECTED])
> > wrote:
> > > --- /dev/null 2007-03-13
ts I will answer another mails, but in general
I think it should be included in -mm so that people could start using
it report real bugs, but not handwaving about possible problems.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
ename_pos;
> + inode = iget(sb, ino);
> + if (!inode)
> + goto fail;
> +
> + super->s_rename_dir = 0;
> + super->s_rename_pos = 0;
> + err = logfs_delete_dd(inode, , pos);
> + ipu
On Sun, Jun 03, 2007 at 08:46:04PM +0200, Jörn Engel ([EMAIL PROTECTED]) wrote:
> --- /dev/null 2007-03-13 19:15:28.862769062 +0100
> +++ linux-2.6.21logfs/fs/logfs/gc.c 2007-06-03 19:18:57.0 +0200
Number of bugs in case of error looks quite sad...
--
Evgeniy Po
On Sun, Jun 03, 2007 at 08:46:04PM +0200, Jörn Engel ([EMAIL PROTECTED]) wrote:
--- /dev/null 2007-03-13 19:15:28.862769062 +0100
+++ linux-2.6.21logfs/fs/logfs/gc.c 2007-06-03 19:18:57.0 +0200
Number of bugs in case of error looks quite sad...
--
Evgeniy Polyakov
;
+ super-s_rename_pos = pos;
+ goto fail;
+ }
+ }
+ return 0;
+fail:
+ LOGFS_BUG(sb);
+ return -EIO;
:)
+}
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
, but in general
I think it should be included in -mm so that people could start using
it report real bugs, but not handwaving about possible problems.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
On Fri, Jun 15, 2007 at 01:14:04PM +0200, Jörn Engel ([EMAIL PROTECTED]) wrote:
On Fri, 15 June 2007 13:03:57 +0400, Evgeniy Polyakov wrote:
On Sun, Jun 03, 2007 at 08:46:04PM +0200, Jörn Engel ([EMAIL PROTECTED])
wrote:
--- /dev/null 2007-03-13 19:15:28.862769062 +0100
+++ linux
nother check must be performed.
This patch resolves the issue with reading from temperature sensor.
Thanks for pointing to that issue.
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
diff --git a/drivers/w1/slaves/w1_therm.c b/drivers/w1/slaves/w1_therm.c
index 732db47..1a6937d 100644
---
will result in exactly same lost of
signals.
> Oleg.
--
Evgeniy Polyakov
-
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/
.
Oleg.
--
Evgeniy Polyakov
-
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/
resolves the issue with reading from temperature sensor.
Thanks for pointing to that issue.
Signed-off-by: Evgeniy Polyakov [EMAIL PROTECTED]
diff --git a/drivers/w1/slaves/w1_therm.c b/drivers/w1/slaves/w1_therm.c
index 732db47..1a6937d 100644
--- a/drivers/w1/slaves/w1_therm.c
+++ b/drivers/w1
On Wed, May 30, 2007 at 10:54:00AM +0200, Ingo Molnar ([EMAIL PROTECTED]) wrote:
>
> * Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> > I did not want to start with another round of ping-pong insults :),
> > but, Ingo, you did not show that kevent works worse. I d
of them
into the ring (if there is a place) and userspace will process them
withouth additional syscalls.
Although syscall overhead is very small, it does exist and should not be
ignored in the design.
>
> Ingo
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the lin
ich might be raised sometimes :).
Although I closed kevent and eventfs projects, I would gladly continue
if we can and want to have progress in that area.
Thanks.
> Ingo
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
and eventfs projects, I would gladly continue
if we can and want to have progress in that area.
Thanks.
Ingo
--
Evgeniy Polyakov
-
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
(if there is a place) and userspace will process them
withouth additional syscalls.
Although syscall overhead is very small, it does exist and should not be
ignored in the design.
Ingo
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On Wed, May 30, 2007 at 10:54:00AM +0200, Ingo Molnar ([EMAIL PROTECTED]) wrote:
* Evgeniy Polyakov [EMAIL PROTECTED] wrote:
I did not want to start with another round of ping-pong insults :),
but, Ingo, you did not show that kevent works worse. I did show that
sometimes it works
> > overflow really occurs?
>
> Indeed it is. You just earned your second beer^Wvodka.
Actually this code looks less encrypted than ext2 for, which definitely
a good sign from reviewer's point of view.
> Jörn
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the
On Wed, May 23, 2007 at 02:58:41PM +0200, Jörn Engel ([EMAIL PROTECTED]) wrote:
> On Sun, 20 May 2007 21:30:52 +0400, Evgeniy Polyakov wrote:
> >
> > In that case segment size must be more than 32 bits, or below
> > transformation will not be correct?
>
> Must it? If
On Wed, May 23, 2007 at 02:58:41PM +0200, Jörn Engel ([EMAIL PROTECTED]) wrote:
On Sun, 20 May 2007 21:30:52 +0400, Evgeniy Polyakov wrote:
In that case segment size must be more than 32 bits, or below
transformation will not be correct?
Must it? If segment size is just 20bit
from reviewer's point of view.
Jörn
--
Evgeniy Polyakov
-
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/
On Thu, May 17, 2007 at 07:10:19PM +0200, Jörn Engel ([EMAIL PROTECTED]) wrote:
> On Thu, 17 May 2007 20:03:11 +0400, Evgeniy Polyakov wrote:
> >
> > Is logfs 32bit fs or 674bit, since although you use 64bit values for
> > offsets, area management and strange converstions
On Thu, May 17, 2007 at 07:10:19PM +0200, Jörn Engel ([EMAIL PROTECTED]) wrote:
On Thu, 17 May 2007 20:03:11 +0400, Evgeniy Polyakov wrote:
Is logfs 32bit fs or 674bit, since although you use 64bit values for
offsets, area management and strange converstions like described below
from
to 2?
Sizes used in on-disk format are rounded to the nearest power-of-two.
> -- Jamie
--
Evgeniy Polyakov
-
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/
format are rounded to the nearest power-of-two.
-- Jamie
--
Evgeniy Polyakov
-
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
appily remove mine and use the
> >new one instead.
> >
> >Opinions?
>
> Why would we need another btree, when there is lib/rbtree.c?
> Or does yours do something fundamentally different?
It is not red-black tree, it is b+ tree.
> Jan
--
Evgeni
ata value obtained via
dev_ofs() into signed 32 bit value.
--
Evgeniy Polyakov
-
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 re
obtained via
dev_ofs() into signed 32 bit value.
--
Evgeniy Polyakov
-
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
and use the
new one instead.
Opinions?
Why would we need another btree, when there is lib/rbtree.c?
Or does yours do something fundamentally different?
It is not red-black tree, it is b+ tree.
Jan
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line unsubscribe
ked for IBM before? Vowels are not evil. ;)
Do you think 'eieio' is a good set? IBM's work too...
We do not get new filesystem each couple of month, so stealing so good
name as 'logfs' is not that bad I think.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsub
. ;)
Do you think 'eieio' is a good set? IBM's work too...
We do not get new filesystem each couple of month, so stealing so good
name as 'logfs' is not that bad I think.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
501 - 600 of 1763 matches
Mail list logo
