On Tue, 5 Jun 2001, Mike Galbraith wrote:
> Yes. If we start writing out sooner, we aren't stuck with pushing a
> ton of IO all at once and can use prudent limits. Not only because of
> potential allocation problems, but because our situation is changing
> rapidly so small corrections done ofte
On Mon, 26 Feb 2001, David S. Miller wrote:
> At gigapacket rates, it becomes an issue. This guy is talking about
> tinkering with new IP _options_, not just the header. So even if the
> IP header itself fits totally in a cache line, the options afterwardsd
> likely will not and thus require an
On Mon, 26 Feb 2001, David S. Miller wrote:
> Not to my knowledge. Routers already change the time to live field,
> so I see no reason why they can't do smart things with special IP
> options either (besides efficiency concerns :-).
A number of ISPs patch the MSS value to 1492 due to the ridicu
On 24 Jan 2001, David Wragg wrote:
> [EMAIL PROTECTED] (Eric W. Biederman) writes:
> > Why do you need such a large buffer?
>
> ext2 doesn't guarantee sustained write bandwidth (in particular,
> writing a page to an ext2 file can have a high latency due to reading
> the block bitmap synchronous
On Tue, 9 Jan 2001, Linus Torvalds wrote:
> The _lower-level_ stuff (ie TCP and the drivers) want the "array of
> tuples", and again, they do NOT want an array of pages, because if
> somebody does two sendfile() calls that fit in one packet, it really needs
> an array of tuples.
A kiobuf simply
On Tue, 9 Jan 2001, Ingo Molnar wrote:
> this is why i ment that *right now* kiobufs are not suited for networking,
> at least the way we do it. Maybe if kiobufs had the same kind of internal
> structure as sk_frag (ie. array of (page,offset,size) triples, not array
> of pages), that would work o
On Tue, 9 Jan 2001, Ingo Molnar wrote:
>
> On Tue, 9 Jan 2001, Stephen C. Tweedie wrote:
>
> > > please study the networking portions of the zerocopy patch and you'll see
> > > why this is not desirable. An alloc_kiovec()/free_kiovec() is exactly the
> > > thing we cannot afford in a sendfile()
On Wed, 11 Oct 2000, Linus Torvalds wrote:
>
> On Thu, 12 Oct 2000, Benjamin C.R. LaHaise wrote:
> >
> > Note the fragment above those portions of the patch where the
> > pte_xchg_clear is done on the page table: this results in a page fault
> > for any other cpu
On Wed, 11 Oct 2000, David S. Miller wrote:
>It's safe because of how x86s hardware works
>
> What about other platforms?
If atomic ops don't work, then software dirty bits are still an option
(read as: it shouldn't break RISC CPUs).
-ben
-
To unsubscribe from this list: s
Hello Linus,
On Wed, 11 Oct 2000, Linus Torvalds wrote:
> I much prefered the dirty fault version.
> What does "quite noticeable" mean? Does it mean that you can see page
> faults (no big deal), or does it mean that you can actually measure the
> performance degradation objectively?
It's a fac
On Mon, 25 Sep 2000 [EMAIL PROTECTED] wrote:
> On Mon, Sep 25, 2000 at 09:23:48PM +0100, Alan Cox wrote:
> > > my prediction is that if you show me an example of
> > > DoS vulnerability, I can show you fix that does not require bean counting.
> > > Am I wrong?
> >
> > I think so. Page tables a
11 matches
Mail list logo
