> Well, on a laptop memory and disk bandwith are rarely wasted - they cost
> battery life.
I've been playing around with different scenarios to see the differences
in performance. A good way to trigger the cache problem is to untar a
couple of kernel source trees or other large amounts of files
> Remember that the first message was about a laptop. At 4:00AM there's
> no activity but the updatedb one (and the other cron jobs). Simply,
> there's no 'accessed-often' data. Moreover, I'd bet that 90% of the
> metadata touched by updatedb won't be accessed at all in the future.
> Laptop users
> If individual pages could be classified as code (text segments),
> data, file cache, and so on, I would specify costs to the paging
> of such pages in or out. This way I can make the system perfer
> to drop a file cache page that has not been accessed for five
> minutes, over a program text
> The same situation appears when using bonding.o. For several years,
> Don Becker's (and derived) network drivers support changing MAC address
> when the interface is down. So Al's /dev/eth//MAC has different
values
> depending on whether bonding is active or not. Should /dev/eth//MAC
> always h
> > > > Any suggestions on heuristics for this ?
> >
> > Not to set rcvbuf to ridiculously low values. The best variant is not
> > to touch SO_*BUF options at all.
> Hmmm... I don't see how not touching buffer values can solve his
> problem at all. His MTU is really HUGE, and in this case 300
>> I can implement one solution by copying the received packets into skb's
>> with the correct length, but that eliminates the performance gains from
>> simply swapping buffers around (and would definately mean no
zero-copy).
> Generally it is a win to copy rather than swap buffers when the
Under certain conditions (e.g. nfs) the socket receive buffer is set to
2048, but in the dma token ring drivers we have the receive skb's set to
mtu size, i.e. anything up to 18200. The default for these drivers is
4096.
So, when any packets are received, even though the skb->len is less than
> We can certainly do that, no problem.
> BUT that won't get a token ring pcmcia card working in the newer
> powerbooks, such as the titanium G4 powerbook, because the PCI host
> bridge doesn't map any cpu addresses to the bottom 16MB of PCI memory
> space. This is not a problem as far as pcmcia
> I would suggest the opposite approach instead: make the PPC just
> support isa_readx/isa_writex instead.
>
> Much simpler, and doesn't need changes to (correct) driver sources.
>
> I bet that the patch will be smaller too. It's a simple case of
> - do the ioremap() _once_ at bootup, save the re
>[EMAIL PROTECTED] wrote:
>>
>> To get the pcmcia ibmtr driver (ibmtr/ibmtr_cs) working on ppc, all the
>> isa_read/write's have to be changed to regular read/write due to the
lack
>> of the isa_read/write functions for ppc.
> Treat it like a PCI device and use ioremap(). Then change isa_readl
To get the pcmcia ibmtr driver (ibmtr/ibmtr_cs) working on ppc, all the
isa_read/write's have to be changed to regular read/write due to the lack
of the isa_read/write functions for ppc.
So, the question is should I simply:
a) change everything to read/write and friends (the way the driver use
Jeff,
Thanks for the comments. This patch has been hanging too long already, the
drivers should be updated as given and I'll work up all the fixes and
another patch.
>> + sisr=readl(olympic_mmio+SISR_RR) ; /* Read & Reset sisr */
> you should also check for 0x, which will happe
Here is a small patch that fixes a memory leak in the ibmtr driver.
Basically the bug occurs because the skb->tail pointer is set past the end
of the skb data buffer. This causes problems when the skb's are cloned
(they are unabled to be freed properly). The result is a leak that
eventually w
Here is the small patch required to enable the olympic driver to work with
the olympic chipset based cardbus tokenring adapters.
The patch is against stock 2.4.2.
(Bigger fixes to enable proper hot-swap and pci api updates are in the
works)
Thanks
Mike Phillips
Linux Token Ring Project
http://
14 matches
Mail list logo
