Re: contigmalloc() breaking Xorg

2012-08-08 Thread Peter Jeremy
On 2012-Aug-06 10:16:13 -0400, John Baldwin  wrote:
>On Thursday, July 12, 2012 8:26:05 am John Baldwin wrote:
>> However, rather add a wiredmalloc(), I think you should just have 
>> bus_dmamem_alloc() call kmem_alloc_attr() directly in this case.  One of the 
>> things I've been meaning to add to bus_dma is a way to allocate other memory 
>> types (e.g. WC memory), and in that case it would be best to just call 
>> kmem_alloc_attr() directly instead.
>
>After my recent changes, I think this would do the above.  What do
>you think of this, and if it looks ok, can you test it?
>
>Index: busdma_machdep.c
>===
>--- busdma_machdep.c   (revision 239020)
>+++ busdma_machdep.c   (working copy)
>@@ -533,13 +533,14 @@ bus_dmamem_alloc(bus_dma_tag_t dmat, void** vaddr,
>   dmat->lowaddr >= ptoa((vm_paddr_t)Maxmem) &&
>   attr == VM_MEMATTR_DEFAULT) {
>   *vaddr = malloc(dmat->maxsize, M_DEVBUF, mflags);
>+  } else if (dmat->nsegments >= btoc(dmat->maxsize) &&
>+  dmat->alignment <= PAGE_SIZE &&
>+  (dmat->boundary == 0 || dmat->boundary >= dmat->lowaddr)) {
>+  /* Page-based multi-segment allocations allowed */
>+  *vaddr = (void *)kmem_alloc_attr(kernel_map, dmat->maxsize,
>+  mflags, 0ul, dmat->lowaddr, attr);
>+  *mapp = &contig_dmamap;
>   } else {
>-  /*
>-   * XXX Use Contigmalloc until it is merged into this facility
>-   * and handles multi-seg allocations.  Nobody is doing
>-   * multi-seg allocations yet though.
>-   * XXX Certain AGP hardware does.
>-   */
>   *vaddr = (void *)kmem_alloc_contig(kernel_map, dmat->maxsize,
>   mflags, 0ul, dmat->lowaddr, dmat->alignment ?
>   dmat->alignment : 1ul, dmat->boundary, attr);

I've tried this on a -current/amd64 box (r239130) that has 2GB RAM and
ZFS.  I looped tar(1)s of several bits of /usr/src whilst doing a "-j2
buildworld" and killing X every 30s for about 7 hours.  (The Xserver
grabs a 8192-page dmamem tag when it starts).  It all seemed to work OK.

I haven't tried it on the box where I originally saw the problem
because that's running 8.x.  I'll have a look at backporting your
and alc@'s fixes when I get some spare time.

-- 
Peter Jeremy


pgpNNsdrw2Bk7.pgp
Description: PGP signature


Re: contigmalloc() breaking Xorg

2012-08-06 Thread John Baldwin
On Thursday, July 12, 2012 8:26:05 am John Baldwin wrote:
> However, rather add a wiredmalloc(), I think you should just have 
> bus_dmamem_alloc() call kmem_alloc_attr() directly in this case.  One of the 
> things I've been meaning to add to bus_dma is a way to allocate other memory 
> types (e.g. WC memory), and in that case it would be best to just call 
> kmem_alloc_attr() directly instead.

After my recent changes, I think this would do the above.  What do you think of
this, and if it looks ok, can you test it?

Index: busdma_machdep.c
===
--- busdma_machdep.c(revision 239020)
+++ busdma_machdep.c(working copy)
@@ -533,13 +533,14 @@ bus_dmamem_alloc(bus_dma_tag_t dmat, void** vaddr,
dmat->lowaddr >= ptoa((vm_paddr_t)Maxmem) &&
attr == VM_MEMATTR_DEFAULT) {
*vaddr = malloc(dmat->maxsize, M_DEVBUF, mflags);
+   } else if (dmat->nsegments >= btoc(dmat->maxsize) &&
+   dmat->alignment <= PAGE_SIZE &&
+   (dmat->boundary == 0 || dmat->boundary >= dmat->lowaddr)) {
+   /* Page-based multi-segment allocations allowed */
+   *vaddr = (void *)kmem_alloc_attr(kernel_map, dmat->maxsize,
+   mflags, 0ul, dmat->lowaddr, attr);
+   *mapp = &contig_dmamap;
} else {
-   /*
-* XXX Use Contigmalloc until it is merged into this facility
-* and handles multi-seg allocations.  Nobody is doing
-* multi-seg allocations yet though.
-* XXX Certain AGP hardware does.
-*/
*vaddr = (void *)kmem_alloc_contig(kernel_map, dmat->maxsize,
mflags, 0ul, dmat->lowaddr, dmat->alignment ?
dmat->alignment : 1ul, dmat->boundary, attr);

-- 
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"


Re: contigmalloc() breaking Xorg

2012-07-12 Thread Alan Cox

On 07/12/2012 07:26, John Baldwin wrote:

[ Adding alc@ for VM stuff, Warner for arm/mips bus dma brokenness ]


When the code underlying contigmalloc() fails in its initial attempt to 
allocate memory and proceeds to launder and reclaim pages, it should 
almost certainly do as the page daemon does and invoke the vm_lowmem 
handlers.  In particular, this should coax the ZFS ARC into releasing 
some of its hoard of wired memory.  Try this:


Index: vm/vm_contig.c
===
--- vm/vm_contig.c  (revision 238372)
+++ vm/vm_contig.c  (working copy)
@@ -192,6 +192,18 @@ vm_contig_grow_cache(int tries, vm_paddr_t low, vm
 {
int actl, actmax, inactl, inactmax;

+   if (tries > 0) {
+   /*
+* Decrease registered cache sizes.
+*/
+   EVENTHANDLER_INVOKE(vm_lowmem, 0);
+
+   /*
+* We do this explicitly after the caches have been drained
+* above.
+*/
+   uma_reclaim();
+   }
vm_page_lock_queues();
inactl = 0;
inactmax = tries < 1 ? 0 : cnt.v_inactive_count;


___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"


Re: contigmalloc() breaking Xorg

2012-07-12 Thread John Baldwin
[ Adding alc@ for VM stuff, Warner for arm/mips bus dma brokenness ]

On Sunday, July 08, 2012 7:05:16 am Peter Jeremy wrote:
> On 2012-Jul-03 21:17:53 +1000, Peter Jeremy  
wrote:
> >I have a reasonably recent 8-stable/amd64 system (r237444) with a "ATI
> >Radeon HD 2400 Pro", xorg-server-1.10.6,1 and xf86-video-ati-6.14.3_1
> >8GB RAM and ZFS.  I'm seeing fairly consistent problems with Xorg
> ...
> >How difficult would it be to modify bus_dmamem_alloc() [at least on
> >x86] to handle multi-segment allocations?
> 
> I think I've managed to create an amd64 bus_dmamem_alloc() that allows
> page-sized allocations as long as no boundary condition is specified
> and no more than page-sized alignment is required (porting it to other
> architectures would be trivial).  I've given it a quick whirl inside a
> VBox and no smoke came out but I'd appreciate someone with a better
> understanding of bus_dma(9) and vm/vm_contig.c giving
> http://www.rulingia.com/bugs/patch-wiredmalloc a once-over.  Note that
> this patch is against 8.x but there's only a trivial difference to head.
> 
> BTW, the comment in busdma_machdep.c:bus_dmamem_alloc()
>* XXX Use Contigmalloc until it is merged into this facility
>* and handles multi-seg allocations.  Nobody is doing
>* multi-seg allocations yet though.
>* XXX Certain AGP hardware does.
> does not appear to be accurate.  Apart from drm, quite a few drivers
> call bus_dma_tag_create(9) with multiple segments and also call
> bus_dmamem_alloc(9) [though I haven't verified that the calls share
> the same bus_dma_tag, so I can't be absolutely certain].

I do think that all tags currently used with bus_dmamem_alloc() only use a 
single segment.  It's a bit of an unfortunate part of the bus_dmamem API
that the size of the allocate is determined by the tag (the tag should be
used for determining the features and constraints of a DMA engine, not really 
the amount of memory to allocate).

However, rather add a wiredmalloc(), I think you should just have 
bus_dmamem_alloc() call kmem_alloc_attr() directly in this case.  One of the 
things I've been meaning to add to bus_dma is a way to allocate other memory 
types (e.g. WC memory), and in that case it would be best to just call 
kmem_alloc_attr() directly instead.

> BTW(2): Whilst studying busdma_machdep.c for arm and mips, I've
> noticed they appear to potentially allocate substantial kernel stack
> under some conditions as several bus_dma(9) functions include:
> bus_dma_segment_t dm_segments[dmat->nsegments];
> What prevents this overflowing the kernel stack?

That does seem dubious.  x86 stores the array in the tag instead.

-- 
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"


Re: contigmalloc() breaking Xorg

2012-07-08 Thread Peter Jeremy
On 2012-Jul-03 21:17:53 +1000, Peter Jeremy  wrote:
>I have a reasonably recent 8-stable/amd64 system (r237444) with a "ATI
>Radeon HD 2400 Pro", xorg-server-1.10.6,1 and xf86-video-ati-6.14.3_1
>8GB RAM and ZFS.  I'm seeing fairly consistent problems with Xorg
...
>How difficult would it be to modify bus_dmamem_alloc() [at least on
>x86] to handle multi-segment allocations?

I think I've managed to create an amd64 bus_dmamem_alloc() that allows
page-sized allocations as long as no boundary condition is specified
and no more than page-sized alignment is required (porting it to other
architectures would be trivial).  I've given it a quick whirl inside a
VBox and no smoke came out but I'd appreciate someone with a better
understanding of bus_dma(9) and vm/vm_contig.c giving
http://www.rulingia.com/bugs/patch-wiredmalloc a once-over.  Note that
this patch is against 8.x but there's only a trivial difference to head.

BTW, the comment in busdma_machdep.c:bus_dmamem_alloc()
 * XXX Use Contigmalloc until it is merged into this facility
 * and handles multi-seg allocations.  Nobody is doing
 * multi-seg allocations yet though.
 * XXX Certain AGP hardware does.
does not appear to be accurate.  Apart from drm, quite a few drivers
call bus_dma_tag_create(9) with multiple segments and also call
bus_dmamem_alloc(9) [though I haven't verified that the calls share
the same bus_dma_tag, so I can't be absolutely certain].

BTW(2): Whilst studying busdma_machdep.c for arm and mips, I've
noticed they appear to potentially allocate substantial kernel stack
under some conditions as several bus_dma(9) functions include:
bus_dma_segment_t dm_segments[dmat->nsegments];
What prevents this overflowing the kernel stack?

-- 
Peter Jeremy


pgp36kekzDWj0.pgp
Description: PGP signature


Re: contigmalloc() breaking Xorg

2012-07-03 Thread Peter Jeremy
On 2012-Jul-03 21:17:53 +1000, Peter Jeremy  wrote:
>Does anyone have a tool that can display physical RAM allocation?
>This would at least allow me to identify offending allocations.
>http://lists.freebsd.org/pipermail/freebsd-hackers/2011-February/thread.html
>asks the same question but just peters out.

That link should be
http://lists.freebsd.org/pipermail/freebsd-hackers/2011-February/034321.html
sorry about the mis-paste.

-- 
Peter Jeremy


pgp1iwrLyMm1P.pgp
Description: PGP signature