Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Test case: async_destroy_001_pos (32-bit only) #5352

Closed
behlendorf opened this issue Oct 31, 2016 · 0 comments
Closed

Test case: async_destroy_001_pos (32-bit only) #5352

behlendorf opened this issue Oct 31, 2016 · 0 comments
Labels
Component: Test Suite Indicates an issue with the test framework or a test case Type: Architecture Indicates an issue is specific to a single processor architecture

Comments

@behlendorf
Copy link
Contributor

When running this test case on a 32-bit system the test case hangs. This is likely due to memory exhaustion during replay. Similar behavior has been reported on very low memory 64-bit systems.
@behlendorf behlendorf added Component: Test Suite Indicates an issue with the test framework or a test case Type: Architecture Indicates an issue is specific to a single processor architecture labels Oct 31, 2016
behlendorf added a commit to behlendorf/zfs that referenced this issue Oct 31, 2016
@behlendorf
Skip async_destroy_001_pos on 32-bit systems
54e291f 
The async_destroy_001_pos test case currently hangs when testing on
a 32-bit system.  Conditionally skip this test case on 32-bit
systems until the root cause is identified and resolved.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Requires-spl: refs/pull/583/head
Issue openzfs#5352
behlendorf added a commit to behlendorf/zfs that referenced this issue Nov 2, 2016
@behlendorf
Skip async_destroy_001_pos on 32-bit systems
779b4a3 
The async_destroy_001_pos test case currently hangs when testing on
a 32-bit system.  Conditionally skip this test case on 32-bit
systems until the root cause is identified and resolved.

Reviewed-by: Tom Caputi <tcaputi@datto.com>
Reviewed-by: Tim Chase <tim@chase2k.com>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Issue openzfs#5352
Issue openzfs#5347
behlendorf added a commit that referenced this issue Nov 2, 2016
@behlendorf
Skip async_destroy_001_pos on 32-bit systems
e676a19 
The async_destroy_001_pos test case currently hangs when testing on
a 32-bit system.  Conditionally skip this test case on 32-bit
systems until the root cause is identified and resolved.

Reviewed-by: Tom Caputi <tcaputi@datto.com>
Reviewed-by: Tim Chase <tim@chase2k.com>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Issue #5352
Issue #5347
@behlendorf behlendorf changed the title Test case async_destroy_001_pos hang on 32-bit system Test case: async_destroy_001_pos (32-bit only) Jan 24, 2017
@behlendorf behlendorf mentioned this issue Oct 10, 2017
Merged
13 tasks
behlendorf added a commit to behlendorf/zfs that referenced this issue Oct 10, 2017
@behlendorf
Fix ARC behavior on 32-bit systems
509c194 
With the addition of the ABD changes consumption of the virtual
address space has been greatly reduced.  This exposed an issue on
CONFIG_HIGHMEM systems where free memory was being calculated
incorrectly.  Functionally this didn't cause any major problems
prior to ABD because a lack of available virtual address space
was used as an indicator of low memory.

This patch makes the following changes to address the issue and
in the process realigns the code further with OpenZFS.  There
are no substantive changes in behavior for 64-bit systems.

* Added CONFIG_HIGHMEM case to the arc_all_memory() and
  arc_free_memory() functions to only consider low memory pages
  on CONFIG_HIGHMEM systems.

* The arc_free_memory() function was updated to return bytes
  instead of pages to be consistent with the other helper
  functions.  In user space we make up some reasonable values
  since currently only testing is performed in this context.

* Adds three new values to the arcstats kstat to provide visibility
  in to the ARC's assessment of the memory situation:
  memory_all_bytes, memory_free_bytes, and memory_available_bytes.

* Added kmem_reap() call to arc_available_memory() for 32-bit
  builds to realign code with OpenZFS.

* Reduced size of test file in /async_destroy_001_pos.ksh to
  speed up test case.  Multiple txgs are still required.

* Move vdevs used by zpool_clear_001_pos and zpool_upgrade_002_pos
  to TEST_BASE_DIR location to speed up test cases.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes openzfs#5352
aerusso pushed a commit to aerusso/zfs that referenced this issue Oct 11, 2017
@behlendorf @aerusso
Fix ARC behavior on 32-bit systems
46e548b 
With the addition of the ABD changes consumption of the virtual
address space has been greatly reduced.  This exposed an issue on
CONFIG_HIGHMEM systems where free memory was being calculated
incorrectly.  Functionally this didn't cause any major problems
prior to ABD because a lack of available virtual address space
was used as an indicator of low memory.

This patch makes the following changes to address the issue and
in the process realigns the code further with OpenZFS.  There
are no substantive changes in behavior for 64-bit systems.

* Added CONFIG_HIGHMEM case to the arc_all_memory() and
  arc_free_memory() functions to only consider low memory pages
  on CONFIG_HIGHMEM systems.

* The arc_free_memory() function was updated to return bytes
  instead of pages to be consistent with the other helper
  functions.  In user space we make up some reasonable values
  since currently only testing is performed in this context.

* Adds three new values to the arcstats kstat to provide visibility
  in to the ARC's assessment of the memory situation:
  memory_all_bytes, memory_free_bytes, and memory_available_bytes.

* Added kmem_reap() call to arc_available_memory() for 32-bit
  builds to realign code with OpenZFS.

* Reduced size of test file in /async_destroy_001_pos.ksh to
  speed up test case.  Multiple txgs are still required.

* Move vdevs used by zpool_clear_001_pos and zpool_upgrade_002_pos
  to TEST_BASE_DIR location to speed up test cases.

Reviewed-by: David Quigley <david.quigley@intel.com>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes openzfs#5352
Closes openzfs#6734
tonyhutter pushed a commit that referenced this issue Oct 16, 2017
@behlendorf @tonyhutter
Fix ARC behavior on 32-bit systems
91b2f6a 
With the addition of the ABD changes consumption of the virtual
address space has been greatly reduced.  This exposed an issue on
CONFIG_HIGHMEM systems where free memory was being calculated
incorrectly.  Functionally this didn't cause any major problems
prior to ABD because a lack of available virtual address space
was used as an indicator of low memory.

This patch makes the following changes to address the issue and
in the process realigns the code further with OpenZFS.  There
are no substantive changes in behavior for 64-bit systems.

* Added CONFIG_HIGHMEM case to the arc_all_memory() and
  arc_free_memory() functions to only consider low memory pages
  on CONFIG_HIGHMEM systems.

* The arc_free_memory() function was updated to return bytes
  instead of pages to be consistent with the other helper
  functions.  In user space we make up some reasonable values
  since currently only testing is performed in this context.

* Adds three new values to the arcstats kstat to provide visibility
  in to the ARC's assessment of the memory situation:
  memory_all_bytes, memory_free_bytes, and memory_available_bytes.

* Added kmem_reap() call to arc_available_memory() for 32-bit
  builds to realign code with OpenZFS.

* Reduced size of test file in /async_destroy_001_pos.ksh to
  speed up test case.  Multiple txgs are still required.

* Move vdevs used by zpool_clear_001_pos and zpool_upgrade_002_pos
  to TEST_BASE_DIR location to speed up test cases.

Reviewed-by: David Quigley <david.quigley@intel.com>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #5352
Closes #6734
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Component: Test Suite Indicates an issue with the test framework or a test case Type: Architecture Indicates an issue is specific to a single processor architecture
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@behlendorf